Network Working Group H. Yokota Internet-Draft KDDI Lab Intended status: Standards Track K. Chowdhury Expires: November 2, 2009 R. Koodli Starent Networks B. Patil Nokia F. Xia Huawei USA May 1, 2009 Fast Handovers for Proxy Mobile IPv6 draft-ietf-mipshop-pfmipv6-04.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 November 2, 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 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. Yokota, et al. Expires November 2, 2009 [Page 1] Internet-Draft Proxy-based Fast Handover May 2009 Abstract Mobile IPv6 (MIPv6) [RFC3775] provides a mobile node with IP mobility when it performs a handover from one access router to another and fast handovers for Mobile IPv6 (FMIPv6) [RFC5268bis] are specified to enhance the handover performance in terms of latency and packet loss. While MIPv6 (and FMIPv6 as well) requires the participation of the mobile node in the mobility-related signaling, Proxy Mobile IPv6 (PMIPv6) [RFC5213] provides IP mobility to mobile nodes that either have or do not have MIPv6 functionality without such involvement. Nevertheless, the basic performance of PMIPv6 in terms of handover latency and packet loss is considered not any different from that of MIPv6. When the fast handover is considered in such an environment, several modifications are needed to FMIPv6 to adapt to the network- based mobility management. This document specifies the usage of Fast Mobile IPv6 (FMIPv6) when Proxy Mobile IPv6 is used as the mobility management protocol. Necessary extensions are specified for FMIPv6 to support the scenario when the mobile node does not have IP mobility functionality and hence is not involved with either MIPv6 or FMIPv6 operations. Yokota, et al. Expires November 2, 2009 [Page 2] Internet-Draft Proxy-based Fast Handover May 2009 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Proxy-based FMIPv6 Protocol Overview . . . . . . . . . . . . . 7 4.1. Protocol Operation . . . . . . . . . . . . . . . . . . . . 8 4.2. Inter-AR Tunneling Operation . . . . . . . . . . . . . . . 14 4.3. IPv4 Support Considerations . . . . . . . . . . . . . . . 15 5. PMIPv6-related Fast Handover Issues . . . . . . . . . . . . . 16 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 17 6.1.1. Handover Initiate (HI) . . . . . . . . . . . . . . . . 17 6.1.2. Handover Acknowledge (HAck) . . . . . . . . . . . . . 18 6.2. Mobility Options . . . . . . . . . . . . . . . . . . . . . 20 6.2.1. Context Request Option . . . . . . . . . . . . . . . . 20 6.2.2. Local Mobility Anchor Address (LMAA) Option . . . . . 22 6.2.3. IPv4 Address Option . . . . . . . . . . . . . . . . . 22 6.2.4. Home Network Prefix Option . . . . . . . . . . . . . . 23 6.2.5. Mobile Node Interface Identifier (MN IID) Option . . . 23 6.2.6. Link-local Address Option . . . . . . . . . . . . . . 23 6.2.7. GRE Key Option . . . . . . . . . . . . . . . . . . . . 23 6.2.8. Vendor-Specific Mobility Option . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . . 27 Appendix A. Applicable Use Cases . . . . . . . . . . . . . . . . 28 A.1. PMIPv6 Handoff Indication . . . . . . . . . . . . . . . . 28 A.2. Local Routing . . . . . . . . . . . . . . . . . . . . . . 28 A.3. Handling of PMIPv6/MIPv6 switching . . . . . . . . . . . . 29 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Yokota, et al. Expires November 2, 2009 [Page 3] Internet-Draft Proxy-based Fast Handover May 2009 1. Requirements notation 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]. Yokota, et al. Expires November 2, 2009 [Page 4] Internet-Draft Proxy-based Fast Handover May 2009 2. Introduction Proxy Mobile IPv6 [RFC5213] provides IP mobility to a mobile node that does not possess Mobile IPv6 [RFC3775] mobile node functionality. A proxy agent in the network performs the mobility management signaling on behalf of the mobile node. This model transparently provides mobility for mobile nodes within a PMIPv6 domain. Nevertheless, the basic performance of PMIPv6 in terms of handover latency and packet loss is considered not any different from that of Mobile IPv6. Fast Handovers for Mobile IPv6 (FMIPv6) [RFC5268bis] describes the protocol to reduce the handover latency for Mobile IPv6 by allowing a mobile node to send packets as soon as it detects a new subnet link and by delivering packets to the mobile node as soon as its attachment is detected by the new access router. This document describes necessary extensions to FMIPv6 for operations in the PMIPv6 domain in order to minimize handover delay and packet loss as well as to transfer network-resident contexts. Yokota, et al. Expires November 2, 2009 [Page 5] Internet-Draft Proxy-based Fast Handover May 2009 3. Terminology This document reuses terminology from [RFC5213], [RFC5268bis] and [RFC3775]. The following terms and abbreviations are additionally used in this document. Access Network (AN): A network composed of link-layer access devices such as access points or base stations providing access to the Access Router (AR) connected to it. Previous Access Network (P-AN): The access network to which the MN is attached before handover. New Access Network (N-AN): The access network to which the MN is attached after handover. Previous Mobile Access Gateway (PMAG): The MAG that manages mobility related signaling for the MN before handover. In this document, the MAG and the Access Router are collocated. New Mobile Access Gateway (NMAG): The MAG that manages mobility related signaling for the MN after handover. In this document, the MAG and the Access Router (AR) are collocated. HO-Initiate: A generic signaling message that indicates the handover of the MN sent from the P-AN to the PMAG. While this signaling is dependent on the access technology, it is assumed that HO- Initiate can carry the information to identify the MN and to assist the PAR resolve the NAR (e.g., the new access point or base station to which the MN is moving). Definition of details in the specification of this message is outside the scope of this document. Yokota, et al. Expires November 2, 2009 [Page 6] Internet-Draft Proxy-based Fast Handover May 2009 4. Proxy-based FMIPv6 Protocol Overview In order to improve the performance during handover (when operations such as attachment to a new network and signaling between mobility agents are involved), the PFMIPv6 protocol in this document specifies a bi-directional tunnel between the Previous MAG (PMAG) and the New MAG (NMAG). In order to enable the NMAG to send the Proxy Binding Update (PBU), the Handover Initiate (HI) and Handover Acknowledge (HAck) messages in [RFC5268bis] are used for context transfer, in which parameters such as MN's NAI, Home Network Prefix (HNP), IPv4 Home Address, are transferred from the PMAG. In this document, the Previous Access Router (PAR) and New Access Router (NAR) are interchangeable with the PMAG and NMAG, respectively. The reference network is illustrated in Figure 1. Since a MN is not directly involved with IP mobility protocol operations, it follows that the MN is not directly involved with fast handover procedures either. Hence, the messages involving the MN in [RFC5268bis] are not used when PMIPv6 is in use. The Router Solicitation for Proxy Advertisement (RtSolPr) and Proxy Router Advertisement (PrRtAdv) are exchanged between the MN and PAR for the MN to formulate the New Care-of Address (NCoA) in advance. Fast Binding Update (FBU) and Fast Binding Acknowledgment (FBack) are also exchanged between these nodes to request the PAR to forward packets to the NAR. The Unsolicited Neighbor Advertisement (UNA) is sent from the MN to NAR to forward the packets to the MN. These messages are not applicable in the PMIPv6 context. Yokota, et al. Expires November 2, 2009 [Page 7] Internet-Draft Proxy-based Fast Handover May 2009 +----------+ | LMA | | | +----------+ / \ / \ / \ +........../..+ +..\..........+ . +-------+-+ .______. +-+-------+ . . | PAR |()_______)| NAR | . . | (PMAG) | . . | (NMAG) | . . +----+----+ . . +----+----+ . . | . . | . . ___|___ . . ___|___ . . / \ . . / \ . . ( P-AN ) . . ( N-AN ) . . \_______/ . . \_______/ . . | . . | . . +----+ . . +----+ . . | MN | ----------> | MN | . . +----+ . . +----+ . +.............+ +.............+ Figure 1: Reference network for fast handover 4.1. Protocol Operation There are two modes of operation in FMIPv6 [RFC5268bis]. In the predictive mode of fast handover, a bi-directional tunnel between the PAR and NAR is established prior to the MN's attachment to the NAR. In the reactive mode, this tunnel establishment takes place after the MN attaches to the NAR. In order eliminate the packet loss during MN's handover (especially when the MN is detached from both links), the downlink packets for the MN need to be buffered either at the PAR (PMAG) or NAR (NMAG), depending on when the packet forwarding is performed. It is hence required that all MAGs have the capability and enough resources to buffer packets for the MNs accommodated by them. Note that the protocol operation specified in the document is transparent to the LMA, hence there is no new functional requirement or change on the LMA. Since the MN is not involved in IP mobility signaling in PMIPv6, the sequence of events illustrating the predictive fast handover are shown in Figure 2. Yokota, et al. Expires November 2, 2009 [Page 8] Internet-Draft Proxy-based Fast Handover May 2009 PMAG NMAG MN P-AN N-AN (PAR) (NAR) LMA | | | | | | | Report | | | | | (a) |-(MN ID,-->| | | | | | New AP ID)| | | | | | | HO Initiate | | | (b) | |--(MN ID, New AP ID)-->| | | | | | | | | | | | | HI | | (c) | | | |-(MN ID, ->| | | | | | MN IID, LMAA) | | | | | | | (d) | | | |<---HAck---| | | | | | (MN ID) | | | | | | | | | | | |HI/HAck(optional) | (e) | | | |<- - - - ->| | | | | #=|<===================| (f) | | | #====DL data=>| | | | | | | | (g) ~~~ | | | | | ~~~ | | | | | | MN-AN connection | AN-MAG connection | | (h) |<---establishment---->|<----establishment----->| | | | | (substitute for UNA) | | | | | | | | (i) |<==================DL data=====================|<=======| | | | | | | (j) |===================UL data====================>|=# | | | | #=|<============# | | | | #=====================>| / | | | | | | \ |(k) | | | | |--PBU-->| | | | | | | | | | |(l) | | | | |<--PBA--| | \ | | | | | | / Figure 2: Predictive fast handover for PMIPv6 (PAR initiated) The detailed descriptions are as follows: (a) The MN detects that a handover is imminent and reports the identifications of itself (MN ID) and the access point (New AP ID) to which the MN is most likely to move. The MN ID could be the NAI or a Link Layer Address (LLA), or any other suitable identifier. This step is access technology specific. In some cases, the P-AN will determine which AP ID the MN is moving to. Yokota, et al. Expires November 2, 2009 [Page 9] Internet-Draft Proxy-based Fast Handover May 2009 (b) The previous access network (P-AN), to which the MN is currently attached, indicates the handover of the MN to the PAR (PMAG). Detailed definition and specification of this message are outside the scope of this document. (c) The PAR sends the HI to the NAR. The HI message MUST include the MN ID and SHOULD include the MN-HNP, the MN-IID and the address of the LMA that is currently serving the MN. (d) The NAR sends the HAck back to the PAR. (e) If it is preferred that the timing of buffering or forwarding should be later than step (c), the NAR may optionally request the PAR at a later and appropriate time to buffer or forward packets by setting U flag [RFC5268bis] or F flag in the HI message, respectively. (f) If the F flag is set in the previous step, a bi-directional tunnel is established between the PAR and NAR and packets destined for the MN are forwarded from the PAR to the NAR over this tunnel. After decapsulation, those packets may be buffered at the NAR. If the connection between the N-AN and NAR has already been established, those packet may be forwarded towards the N-AN; this is access technology specific. (g) The MN undergoes handover to the New Access Network (N-AN). (h) The MN establishes a physical link connection with the N-AN (e.g., radio channel assignment), which in turn triggers the establishment of a link-layer connection between the N-AN and NAR if not yet established. An IP layer connection setup may be performed at this time (e.g., PPP IPv6CP) or at a later time (e.g., stateful or stateless auto address configuration). This step can be a substitute for the UNA in [RFC5268bis], but since they are all access technology specific, details are outside the scope of this document. (i) The NAR starts to forward packets destined for the MN via the N-AN. (j) The uplink packets from the MN are sent to the NAR via the N-AN and the NAR forwards them to the PAR. The PAR then sends the packets to the LMA that is currently serving the MN. (k) The NAR (NMAG) sends the Proxy Binding Update (PBU) to the LMA, whose address is provided in (c). Steps (k) and (l) are not part of the fast handover procedure, but shown for reference. Yokota, et al. Expires November 2, 2009 [Page 10] Internet-Draft Proxy-based Fast Handover May 2009 (l) The LMA sends back the Proxy Binding Acknowledgment (PBA) to the NAR (NMAG). From this time on, the packets to/from the MN go through the NAR instead of the PAR. According to Section 4 of [RFC5268bis], the PAR establishes a binding between the PCoA and NCoA to forward packets for the MN to the NAR, and the NAR creates a proxy NCE to receive those packets for the NCoA before the MN arrives. In the case of PMIPv6, however, the only address that is used by the MN is MN-HoA. Hence the PAR forwards MN's packets to the NAR instead of the NCoA. FMIPv4 [RFC4988] specifies forwarding when the MN uses HoA as its on-link address rather than the care-of address. The usage in PMIPv6 is similar to that in FMIPv4, where the address is used by the MN is based on Home Network Prefix. Hence the PAR forwards MN's packets to the NAR instead of the NCoA. The NAR then simply decapsulates those packets and delivers them to the MN. Since the NAR obtains the LLA (MN IID) and MN-HNP by the HI, it can create the NCE for the MN and deliver packets to it even before the MN can perform Neighbor Discovery. For the uplink packets from the MN after handover in (j), the NAR forwards the packets to the PAR through the tunnel established in step (f). The PAR then decapsulates and sends them to the LMA. The timing of the context transfer and that of packet forwarding may be different. Thus, a new flag 'F' and the Option Code values for it in the HI message are defined to request forwarding. To request buffering, 'U' flag has already been defined in [RFC5268bis]. If the PAR receives the HI message with F flag set and the Option Code value being 2, it starts forwarding packets for the MN. The HI message with U flag set may be sent earlier if the timing of buffering is different from that of forwarding. If packet forwarding is completed, the PAR MAY send the HI message with F flag set and the Option Code value being 3. By this message, the ARs on both ends can tear down the forwarding tunnel synchronously. The IP addresses in the headers of those user packets are summarized below: In (f), Inner source address: IP address of the CN Inner destination address: HNP or IPv4-MN-HoA Outer source address: IP address of the PAR (PMAG) Yokota, et al. Expires November 2, 2009 [Page 11] Internet-Draft Proxy-based Fast Handover May 2009 Outer destination address: IP address of the NAR (NMAG) In (i), Source address: IP address of the CN Destination address: HNP or IPv4-MN-HoA In (j), - from the MN to the NMAG, Source address: HNP or IPv4-MN-HoA Destination address: IP address of the CN - from the NMAG to the PMAG, Inner source address: HNP or IPv4-MN-HoA Inner destination address: IP address of the CN Outer source address: IP address of the NAR (NMAG) Outer destination address: IP address of the PAR (PMAG) - from the PMAG to the LMA, Inner source address: HNP or IPv4-MN-HoA Inner destination address: IP address of the CN Outer source address: IP address of the PAR (PMAG) Outer destination address: IP address of the LMA The encapsulation type for these user packets SHOULD follow that used in the tunnel between the LMA and MAG (e.g., IPv6-in-IPv6 [RFC5213] or GRE [GREKEY]). In the case of the reactive handover for PMIPv6, since the MN does not send either the FBU or UNA, it would be more natural that the NAR sends the HI to the PAR after the MN has moved to the new link. The NAR then needs to obtain the information of the PAR beforehand. Such information could be provided, for example, by the MN sending the AP-ID on the old link and/or by the lower-layer procedures between the P-AN and N-AN. The exact method is not specified in this document. Figure 3 illustrates the reactive fast handover procedures Yokota, et al. Expires November 2, 2009 [Page 12] Internet-Draft Proxy-based Fast Handover May 2009 for PMIPv6, where the bi-directional tunnel establishment is initiated by the NAR. PMAG NMAG MN P-AN N-AN (PAR) (NAR) LMA | | | | | | (a) ~~~ | | | | | ~~~ | | | | | | MN-AN connection | AN-MAG connection | | (b) |<--establishment-->|<-------establishment------>| | |(MN ID, Old AP ID) | (MN ID, Old AP ID) | | | | |(substitute for UNA and FBU)| | | | | | | | | | | | HI | | (c) | | | |<---(MN ID) ---| | | | | | | | | | | | HAck | | (d) | | | |---(MN ID, --->| | | | | | MN IID, LMAA) | | | | | | | | (e) | | | #=|<=======================| | | | #================>|=# | |<====================DL data======================# | | | | | | | (f) |=====================UL data===================>|=# | | | | #=|<================# | | | | #=========================>| | | | | | | / | | | | | | \ |(g) | | | | |--PBU-->| | | | | | | | | | |(h) | | | | |<--PBA--| | \ | | | | | | / Figure 3: Reactive fast handover for PMIPv6 (NAR initiated) The detailed descriptions are as follows: (a) The MN undergoes handover from the P-AN to the N-AN. The AP-ID on the old link may be provided by the MN to help identify the PMAG on the new link. (b) The MN establishes a connection (e.g., radio channel) with the N-AN, which triggers the establishment of the connection between the N-AN and NAR. The MN ID is transferred to the NAR for the subsequent procedures. The AP-ID on the old link may also be provided by the MN to help identify the PMAG on the new link. This can be regarded as a substitute for the UNA and FBU. Yokota, et al. Expires November 2, 2009 [Page 13] Internet-Draft Proxy-based Fast Handover May 2009 (c) The NAR sends the HI to the PAR. The HI message MUST include the MN ID. The Context Request Option MAY be included to request additional context information on the MN to the PAR. (d) The PAR sends the HAck back to the NAR. The HAck message MUST include the HNP and/or IPv4-MN-HoA that is corresponding to the MN ID in the HI message and SHOULD include the MN-IID and the LMA address that is currently serving the MN. The context information requested by the NAR MUST be included. (e) If F flag in the HI is set, a bi-directional tunnel is established between the PAR and NAR and packets destined for the MN are forwarded from the PAR to the NAR over this tunnel. After decapsulation, those packets are delivered to the MN via the N-AN. (f) The uplink packets from the MN are sent to the NAR via the N-AN and the NAR forwards them to the PAR. The PAR then sends the packets to the LMA that is currently serving the MN. Steps (g)-(h) are the same as (k)-(l) in the predictive fast handover procedures. In step (c), The IP address of the PAR needs to be resolved by the NAR to send the HI to the PAR. This information may come from the N-AN or some database that the NAR can access. 4.2. Inter-AR Tunneling Operation When the PMAG (PAR) or NMAG (NAR), depending on the fast handover mode, receives the HI message with the F flag set, it prepares to send/receive the MN's packets to/from the other MAG and returns the HAck message with the same sequence number. The necessary information MUST be transferred in the HI message to distinguish MN's packets for forwarding in advance or at this time. Such information includes the HoA of the MN and/or GRE key(s). For the downlink packets, the PMAG redirects MN's packets from the LMA towards the NMAG and if the MN is ready to receive those packets or the N-AN can handle them regardless of the state of the MN, the NAR should immediately send them towards the N-AN; otherwise it should buffer them until the MN is ready. For the uplink packets, the NMAG SHOULD redirect them from the MN towards the PMAG and the PMAG sends them to the LMA. Depending on the implementation, the NMAG MAY send them directly to the LMA. When the PMAG or NMAG receives the HI message with the U flag set, it prepares to buffer the MN's packets and returns the HAck message with the same sequence number. It MUST be followed by another HI message Yokota, et al. Expires November 2, 2009 [Page 14] Internet-Draft Proxy-based Fast Handover May 2009 with the F flag set at an appropriate time to forward the buffered packets. If the MAG that received the HI message encounters an erroneous situation (e.g., insufficient buffer space), it SHOULD immediately send the HAck message with the cause of the error and cancel all tunneling operation. 4.3. IPv4 Support Considerations The motivation and usage scenarios of IPv4 protocol support by PMIPv6 are described in [IPv4PMIPv6]. The scope of IPv4 support covers the following two features: o IPv4 Home Address Mobility Support, and o IPv4 Transport Support. As for IPv4 Home Address Mobility Support, the MN acquires IPv4 Home Address (IPv4-MN-HoA) and in the case of handover, the PMAG needs to transfer IPv4-MN-HoA to the NMAG, which is the inner destination address of the packets forwarded on the downlink. For this purpose, a new option called IPv4 Address Option is defined in this document. In order to provide IPv4 Transport Support, the NMAG needs to know the IPv4 address of the LMA (IPv4-LMAA) to send PMIPv6 signaling messages to the LMA in the IPv4 transport network. In this case, a new option called LMA Address (LMAA) option is used so as to convey IPv4-LMAA from the PMAG to NMAG. The supported encapsulation type follows Section 6.10.2 in [RFC5213], that is, IPv4, IPv4-UDP and IPv4-UDP-TLV. Yokota, et al. Expires November 2, 2009 [Page 15] Internet-Draft Proxy-based Fast Handover May 2009 5. PMIPv6-related Fast Handover Issues The protocol specified in this document enables the NMAG to obtain parameters which would otherwise be available only by communicating with the LMA. For instance, the HNP and/or IPv4-MN-HoA of a MN are made available to the NMAG through context transfer. This allows the NMAG to perform some procedures that may be beneficial. For instance, the NMAG could send a Router Advertisement (RA) with the HNP option to the MN as soon as it's link attachment is detected (e.g., via receipt of a Router Solicitation message). Such an RA is recommended, for example, in scenarios where the MN uses a new radio interface while attaching to the NMAG; since the MN does not have information regarding the new interface, it will not be able to immediately send packets without first receiving an RA with HNP. Especially, in the reactive fast handover, the NMAG gets to know the HNP assigned to the MN on the previous link at step (d) in Figure 3. In order to reduce the communication disruption time, the NMAG SHOULD accept the MN to keep using the same HNP and to send uplink packets before that step upon MN's request. However, if the HAck from the PMAG returns a different HNP or the subsequent PMIPv6 binding registration for the HNP fails for some reason, then the NMAG MUST withdraw the advertised HNP by sending another RA with zero prefix lifetime for the HNP in question. This operation is the same as described in Section 6.12 of [RFC5213]. The protocol specified in this document is applicable regardless of whether link-layer addresses are used between a MN and its access router. A MN should be able to continue sending packets on the uplink even when it changes link. When link-layer addresses are used, the MN performs Neighbor Unreachability Detection (NUD) [RFC4861], after attaching to a new link, probing the reachability of its default router. If the new router's interface is configured to respond to queries sent to link-layer addresses than its own (e.g., set to promiscuous mode), then it can respond to the NUD probe, providing its link-layer address in the solicited Neighbor Advertisement. Implementations should allow the MN to continue to send uplink packets while it is performing NUD. Yokota, et al. Expires November 2, 2009 [Page 16] Internet-Draft Proxy-based Fast Handover May 2009 6. Message Formats This document defines new Mobility Header messages for the extended HI and Hack and new mobility options for conveying context information. 6.1. Mobility Header 6.1.1. Handover Initiate (HI) This section defines extensions to the HI message in [RFC5268bis]. The format of the Message Data field in the Mobility Header is as follows: 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 +-------------------------------+ | Sequence # | +-+-+-+---------+---------------+-------------------------------+ |S|U|F|Reserved | Code | | +-+-+-+---------+---------------+ | | | . . . Mobility options . . . | | +---------------------------------------------------------------+ IP Fields: Source Address The IP address of PMAG or NMAG Destination Address The IP address of the peer MAG Message Data: Sequence # Same as [RFC5268bis]. S flag Defined in [RFC5268bis] and MUST be set to zero in this specification. Yokota, et al. Expires November 2, 2009 [Page 17] Internet-Draft Proxy-based Fast Handover May 2009 U flag Buffer flag. Same as [RFC5268bis]. F flag Forwarding flag. Used to request to forward the packets for the MN. Reserved Same as [RFC5268bis]. Code [RFC5268bis] defines this field and its values 0 and 1. In this specification, if F flag is not set, this field MUST be set to zero. Otherwise, it has the following meaning: 2: Forwarding is not requested 3: Request forwarding 4: Indicate the completion of forwarding Mobility options: This field contains one or more mobility options, whose encoding and formats are defined in [RFC3775]. At least one mobility option MUST uniquely identify the target MN (e.g., the Mobile Node Identifier Option defined in RFC4283) and the transferred context MUST be for one MN per message. In addition, the NAR can request necessary mobility options by the Context Request Option defined in this document. Context Request Option This option MAY be present to request context information typically by the NAR to the PAR in the NAR-initiated fast handover. 6.1.2. Handover Acknowledge (HAck) This section defines extensions to the HAck message in[RFC5268bis]. The format of the Message Data field in the Mobility Header is as follows: Yokota, et al. Expires November 2, 2009 [Page 18] Internet-Draft Proxy-based Fast Handover May 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 +-------------------------------+ | Sequence # | +-+-+-----------+---------------+-------------------------------+ |U|F| Reserved | Code | | +-+-+-----------+---------------+ | | | . . . Mobility options . . . | | +---------------------------------------------------------------+ IP Fields: Source Address Copied from the destination address of the Handover Initiate message to which this message is a response. Destination Address Copied from the source address of the Handover Initiate message to which this message is a response. Message Data: The usages of Sequence # and Reserved fields are exactly the same as those in [RFC5268bis]. U, F flags Same as defined in Section 6.1.1. Code Code values 0 through 4 and 128 through 130 are defined in [RFC5268bis]. In this specification, the meaning of Code value 0 is modified, 128 through 130 are reused, and 5, 6, 131 and 132 are newly defined. 0: Handover Accepted 5: Context Transfer Successful or Accepted Yokota, et al. Expires November 2, 2009 [Page 19] Internet-Draft Proxy-based Fast Handover May 2009 6: All available Context Transferred 128: Handover Not Accepted, reason unspecified 129: Administratively prohibited 130: Insufficient resources 131: Requested Context Not Available 132: Forwarding Not Available Mobility options: This field contains one or more mobility options, whose encoding and formats are defined in [RFC3775]. The mobility option that uniquely identifies the target MN MUST be copied from the corresponding HI message and the transferred context MUST be for one MN per message. Requested option(s) All the context information requested by the Context Request Option in the HI message SHOULD be present in the HAck message. The other cases are described below. In the case of the PAR-initiated fast handover, when the PAR sends the HI message to the NAR with the context information and the NAR successfully receives it, the NAR returns the HAck message with Code value 5. In the case of the NAR-initiated fast handover, when the NAR sends the HI message to the PAR with or without Context Request Option, the PAR returns the HAck message with the requested or default context information (if any). If all available context information is transferred, the PAR sets the Code value in the HAck message to 6. If more context information is available, the PAR sets the Code value in the HAck to 5 and the NAR MAY send new HI message(s) to retrieve the rest of the available context information. If none of the requested context information is available, the PAR returns the HAck message with Code value 131 without any context information. 6.2. Mobility Options 6.2.1. Context Request Option This option is sent in the HI message to request context information on the MN. If a default set of context information is defined and always sufficient, this option is not mandatory. This option is more useful to retrieve additional or dynamically selected context information. Yokota, et al. Expires November 2, 2009 [Page 20] Internet-Draft Proxy-based Fast Handover May 2009 Context Request Option is typically used for the reactive (NAR- initiated) fast handover mode to retrieve the context information from the PAR. When this option is included in the HI message, all the requested context information SHOULD be included in the HAck message in the corresponding mobility option(s) (e.g., HNP, LMAA or MN-IID mobility options). 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 | Option-Length | Reserved | +---------------+---------------+-------------------------------+ | Req-type-1 | Req-length-1 | Req-type-2 | Req-length-2 | +---------------------------------------------------------------+ | ... | Option-Type TBD1 Option-Length The length in octets of this option, not including the Option Type and Option Length fields. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Req-type-n The type value for the n'th requested option. Req-length-n The length of the n'th requested option excluding the Req-type-n and Req-length-n fields. In the case where there are only Req-type-n and Req-length-n fields, the value of the Req-length-n is set to zero. If additional information besides the Req-type-n is necessary to uniquely specify the requested context, such information follows after the Req-length-n. For example, when the requested context is the Vendor- Specific Option described in Section 6.2.8, the requested option format looks as follows: | ... | +---------------+---------------+-------------------------------+ | Req-type-N=19 | Req-length-N=5| Vendor-ID | +-------------------------------+---------------+---------------+ | Vendor-ID | Sub-Type | | +-----------------------------------------------+ | | ... | The exact values in the Vendor-ID and Sub-Type are outside the scope of this document. Yokota, et al. Expires November 2, 2009 [Page 21] Internet-Draft Proxy-based Fast Handover May 2009 6.2.2. Local Mobility Anchor Address (LMAA) Option This option is used to transfer the Local Mobility Anchor IPv6 Address (LMAA) or its IPv4 Address (IPv4-LMAA), with which the MN is currently registered. The detailed definition of the LMAA is described in [RFC5213]. 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 | Option-Length | Option-Code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Mobility Anchor Address ... | Option-Type TBD2 Option-Length 18 or 6 Option-Code 0 Reserved 1 IPv6 address of the LMA (LMAA) 2 IPv4 address of the LMA (IPv4-LMAA) Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Local Mobility Anchor Address If Option-Code is 1, the LMA IPv6 address (LMAA) is inserted. If Option-Code is 2, the LMA IPv4 address (IPv4-LMA) is inserted. 6.2.3. IPv4 Address Option As described in Section 4.3, if the MN is IPv4-only mode or dual- stack mode, the MN requires IPv4 home address (IPv4-MN-HoA). This option has alignment requirement of 4n. 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 | Option-Length | Option-Code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Yokota, et al. Expires November 2, 2009 [Page 22] Internet-Draft Proxy-based Fast Handover May 2009 Option-Type TBD3 Option-Length 6 Option-Code 0 Reserved 1 IPv4-MN-HoA Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. IPv4 Address IPv4 address specified in Option-Code 6.2.4. Home Network Prefix Option This option is used to transfer the home network prefix that is assigned to the MN in the P-AN. The Home Network Prefix Option defined in [RFC5213] is used for this. 6.2.5. Mobile Node Interface Identifier (MN IID) Option This option is used to transfer the interface identifier of the MN that is used in the P-AN. The Mobile Node Interface Identifier Option defined in [RFC5213] is used for this. 6.2.6. Link-local Address Option This option is used to transfer the link-local address of the PAR (PMAG). The Link-local Address Option defined in [RFC5213] is used for this. 6.2.7. GRE Key Option This option is used to transfer the GRE Key for the MN's data flow over the bi-directional tunnel between the PAR and NAR. The message format of this option follows the GRE Key Option defined in [GREKEY]. The GRE Key value uniquely identifies each flow and the sender of this option expects to receive packets of the flow from the peer AR with this value. 6.2.8. Vendor-Specific Mobility Option This option is used to transfer any other information defined in this document. The format of this option follows the Vendor-Specific Mobility Option defined in [RFC5094]. The exact values in the Vendor ID, Sub-Type and Data fields are outside the scope of this document. Yokota, et al. Expires November 2, 2009 [Page 23] Internet-Draft Proxy-based Fast Handover May 2009 7. Security Considerations Security issues for this document follow those for PMIPv6 [RFC5213] and FMIPv6 [RFC5268bis]. In PMIPv6, the MAG and LMA are assumed to share security associations. In FMIPv6, the access routers (i.e., the PMAG and NMAG in this document) are assumed to share security associations. The Handover Initiate (HI) and Handover Acknowledgement (HAck) messages exchanged between the PMAG and NMAG MUST be protected using end-to-end security association(s) offering integrity and data origin authentication. The PMAG and the NMAG MUST implement IPsec [RFC4301] for protecting the HI and HAck messages. IPsec Encapsulating Security Payload (ESP) [RFC4303] in transport mode with mandatory integrity protection SHOULD be used for protecting the signaling messages. Confidentiality protection SHOULD be used if sensitive context related to the mobile node is transferred. IPsec ESP [RFC4303] in tunnel mode MAY be used to protect the MN's packets at the time of forwarding if protection of data traffic is required. Yokota, et al. Expires November 2, 2009 [Page 24] Internet-Draft Proxy-based Fast Handover May 2009 8. IANA Considerations This document defines two new mobility options, which are described in Section 6.2. The Type value for these options are assigned from the same numbering space as allocated for the other mobility options, as defined in [RFC3775]. Mobility Options Value Description Reference ----- ------------------------------------- ------------- TBD1 Context Request Option Section 6.2.1 TBD2 Local Nobility Anchor Address Option Section 6.2.2 TBD3 IPv4 Address Option Section 6.2.3 Yokota, et al. Expires November 2, 2009 [Page 25] Internet-Draft Proxy-based Fast Handover May 2009 9. Acknowledgments The authors would like to specially thank Vijay Devarapalli and Sri Gundavelli for their thorough reviews of this document. The authors would also like to thank Charlie Perkins, Desire Oulai, Ahmad Muhanna, Giaretta Gerardo, Domagoj Premec, Marco Liebsch, Fan Zhao, David Cypher, Julien Laganier and Pierrick Seite for their passionate discussions in the working group mailing list. Yokota, et al. Expires November 2, 2009 [Page 26] Internet-Draft Proxy-based Fast Handover May 2009 10. References 10.1. Normative References [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5268bis] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", draft-ietf-mipshop-rfc5268bis-01.txt, March 2009. [RFC3775] Johnson, D., "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4988] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", RFC 4988, October 2007. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 Vendor Specific Option", RFC 5094, December 2007. 10.2. Informative References [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [IPv4PMIPv6] Wakikawa, R., Ed. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-12.txt, April 2009. [GREKEY] Muhanna, A., Ed., "GRE Key Option for Proxy Mobile IPv6", draft-ietf-netlmm-grekey-option-08.txt, April 2009. Yokota, et al. Expires November 2, 2009 [Page 27] Internet-Draft Proxy-based Fast Handover May 2009 Appendix A. Applicable Use Cases A.1. PMIPv6 Handoff Indication PMIPv6 [RFC5213] defines the Handoff Indicator Option and describes the type of the handoff and the values to set to the option. This document proposes one approach to determining the handoff type by the NMAG when the handoff of the MN is executed. According to [RFC5213], the following handoff types are defined: 0) Reserved 1) Attachment over a new interface 2) Handoff between two different interfaces of the mobile node 3) Handoff between mobile access gateways for the same interface 4) Handoff state unknown 5) Handoff state not changed (Re-registration) By using the MN Interface Identifier (MN IID) option, which is defined in this document, the following solution can be considered. When the NMAG receives the MN IID used in the P-AN from the PMAG via the HI or HAck messages, the NMAG compares it with the new MN IID that is obtained from the MN in the N-AN. If these two MN IIDs are the same, the handover type falls into 3) and the Handoff Indicator value is set to 3. If these two MN IIDs are different, the handover is likely to be 2) since the HI/HAck message exchange implies that this is a handover not a multi-homing, therefore the Handoff Indicator value can be set to 2. If there is no HI/Hack exchange performed prior to the network attachment of the MN in the new network, the NMAG may infer that this is a multi-homing case and set the Handoff Indicator value to 1. In the case of re-registration, the MAG, to which the MN is attached, can determine if the handoff state is not changed, so the MAG can set the HI value to 5 without any additional information. If none of them can be assumed, the NMAG may set the value to 4. A.2. Local Routing Section 6.10.3 in [RFC5213] describes that if EnableMAGLocalRouting flag is set, when two mobile nodes are attached to one MAG, the traffic between them may be locally routed. If one mobile node moves from this MAG (PMAG) to another MAG (NMAG) and if the PMAG does not detect the MN's detachment, it will continue to forward packets Yokota, et al. Expires November 2, 2009 [Page 28] Internet-Draft Proxy-based Fast Handover May 2009 locally forever. This situation is more likely to happen in the reactive fast handover with WLAN access, which does not have the capability to detect the detachment of the MN in a timely manner. PFMIPv6 can be applied to handle this case. When the MN attaches to the NMAG, it sends the HI message to the PMAG, which makes it realize the detachment of the MN. The PMAG immediately stops the local routing and sends the packets for the MN towards the LMA, which in turn forwards them to the NMAG over the PMIPv6 tunnel. A.3. Handling of PMIPv6/MIPv6 switching If the network that the MN has moved to does not support PMIPv6 but only MIPv6 (i.e. there exists a MIPv6 HA) and the MN supports MIPv6 at the same time, the MN and HA can exchange BU/BA instead of PBU/PBA (e.g., at steps (k) and (l) in Figure 2). If this is the case, the LMA and HA will most likely be collocated and the LMA (HA) address should be maintained in the new network for communication continuity. Since the LMA (HA) address is transferred to the NAR in the HI/HAck exchange, the MN can retrieve it at or after the handover by way of, e.g., the authentication or DHCP procedure. Yokota, et al. Expires November 2, 2009 [Page 29] Internet-Draft Proxy-based Fast Handover May 2009 Appendix B. Change Log Changes at -00 * Added separate sections for MH and ICMP. * Clarified usage of HNP and IPv4-MN-HoA throughout the document. * Added IANA Considerations. * Added section on Other Considerations, including operation of uplink packets when using link-layer addresses, multiple interface usage and transmission of RA to withdraw HNP in the event of failure of PMIP6 registration. * Revised Security Considerations. Changes from -00 to -01 * Removed ICMPv6-based message format. * Clarified HI/HAck exchange in the predictive mode (step (e) in Figure 2). * Clarified information retrieval about the PMAG in the reactive mode. * Removed the extension to the GRE Key Option. * Clarified the handoff type considerations in Appendix A. * Home Network Prefix Option, Link-local Address Option and Vendor-Specific Mobility Option are added. Changes from -01 to -02 * Aligned HI/HAck message formats with [RFC5268bis] (draft-ietf-mipshop-rfc5268bis-00.txt). * Revised Section 8 removing the request for the type assignment of HI/HAck Mobility Headers. Changes from -02 to -03 * Updated HI/HAck message formats according to draft-ietf-mipshop-rfc5268bis-01.txt. Yokota, et al. Expires November 2, 2009 [Page 30] Internet-Draft Proxy-based Fast Handover May 2009 * Cleaned up Figure 2 and Figure 3. * Moved PMIP domain boundary crossing situation in Section 4.1 to Appendix A.3. * Removed the alternative protocol operation with an unsolicited HAck from Section 4.1. * Modified Code values in the HAck message in order to avoid collision with those in [RFC5268bis]. * Clarified the usage scenarios of Context Request Option. * Modified the description of Code values in the HAck message. * Changed the container for the IPv4-LMAA from IPv4 Address option to the LMAA option. * Made Confidentiality protection "SHOULD" for context transfer. Changes from -03 to -04 * Added more explanations about MIPv6, FMIPv6 and PMIPv6 in Abstract. * Moved Figure 1 to Section 4. * More clearly Indicated the FMIPv6 messages that are not applicable In the PMIPv6 context. * Mandated the support of IP Sec on the PMAG and NMAG in order to protect signaling and user packets and the context information. * Added a new section for the inter-AR tunneling operation (Section 4.2). * Added descriptions about the encapsulation type in Sections 4.1 and 4.3. * Added a description about buffering requirements on the MAG in Section 4.1. * Added a description about the timing of L2 and L3 connection establishments in Section 4.1. * Added a new section for PMIPv6-related fast handover issues (Section 5) and a description about preferable behaviors of the MN and MAG to reduce packet loss. Yokota, et al. Expires November 2, 2009 [Page 31] Internet-Draft Proxy-based Fast Handover May 2009 * Added Acknowledgments section (Section 9). * Added a new section for local routing in Appendix (A.2). Yokota, et al. Expires November 2, 2009 [Page 32] Internet-Draft Proxy-based Fast Handover May 2009 Authors' Addresses Hidetoshi Yokota KDDI Lab 2-1-15 Ohara, Fujimino Saitama, 356-8502 JP Email: yokota@kddilabs.jp Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA 01876 US Email: kchowdhury@starentnetworks.com Rajeev Koodli Starent Networks 30 International Place Tewksbury, MA 01876 US Email: rkoodli@starentnetworks.com Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 US Email: basavaraj.patil@nokia.com Frank Xia Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 US Email: xiayangsong@huawei.com Yokota, et al. Expires November 2, 2009 [Page 33]