Network Working Group H. Yokota Internet-Draft KDDI Lab Intended status: Standards Track K. Chowdhury Expires: August 29, 2008 Starent Networks R. Koodli B. Patil Nokia Siemens Networks F. Xia Huawei USA February 26, 2008 Fast Handovers for PMIPv6 draft-yokota-mipshop-pfmipv6-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 29, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Yokota, et al. Expires August 29, 2008 [Page 1] Internet-Draft Proxy-based Fast Handover February 2008 Abstract This document specifies the usage of FMIPv6 when Proxy Mobile IPv6 is applied for the mobility management protocol. Necessary amendments are shown for FMIPv6 to work under the condition that the mobile node does not have IP mobility functionality and it is not involved with either MIPv6 or FMIPv6 operations. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Proxy-based FMIPv6 Protocol Overview . . . . . . . . . . . . . 7 4.1. Protocol Operation . . . . . . . . . . . . . . . . . . . . 7 4.2. Handoff Type Considerations . . . . . . . . . . . . . . . 13 4.3. IPv4 Support Considerations . . . . . . . . . . . . . . . 14 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Handover Initiate (HI) . . . . . . . . . . . . . . . . . . 15 5.2. Handover Acknowledge (HAck) . . . . . . . . . . . . . . . 16 5.3. Context Request Option . . . . . . . . . . . . . . . . . . 18 5.4. Tunnel-ID Option . . . . . . . . . . . . . . . . . . . . . 19 5.5. Mobile Node Interface Identifier (MN IID) Option . . . . . 19 5.6. New option-code for the IP Address Option . . . . . . . . 20 5.7. IPv4 Address Option . . . . . . . . . . . . . . . . . . . 20 5.8. Vendor Specific Option . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Normative References . . . . . . . . . . . . . . . . . . . 24 7.2. Informative References . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 26 Yokota, et al. Expires August 29, 2008 [Page 2] Internet-Draft Proxy-based Fast Handover February 2008 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 [1]. Yokota, et al. Expires August 29, 2008 [Page 3] Internet-Draft Proxy-based Fast Handover February 2008 2. Introduction Proxy Mobile IPv6 [2] provides IP mobility to a mobile node that does not have Mobile IPv6 [4] functionality. The proxy agent in the network performs the signaling and does the mobility management on behalf of the mobile node. Although the signaling between the mobile node and the network can be saved, the basic performance for handover such as handover latency is considered to be not different from that of Mobile IPv6. To improve handover latency due to Mobile IPv6 procedures, fast handovers for MIPv6 is specified in FMIPv6[3]. By applying the FMIPv6 solution to Proxy MIPv6 as well, it is expected that the handover latency due to Proxy MIPv6 procedures will be improved as much. However, Mobile IPv6 and Proxy MIPv6 are intrinsically different in the sense that the mobile node is not involved with IP mobility and hence does not directly handle the care-of address. Hence, there are some issues in directly applying the original specifications of FMIPv6 to Proxy MIPv6. This document identifies those differences and specifies amendments to apply FMIPv6 solution principles to Proxy MIPv6. Yokota, et al. Expires August 29, 2008 [Page 4] Internet-Draft Proxy-based Fast Handover February 2008 3. Terminology This document refers to [2][3][4] for terminology. The following terms and abbreviations are additionally used in this document. The reference network is illustrated in Figure 1. 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 (AR) are collocated. New Mobile Access Gateway (NMAG): The MAG that manages mobility related signaling for the MN after handover. HO-Initiate: A generic signaling 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 specify the MN and to help the PAR resolve the NAR (e.g. the new access point or base station to which the MN is moving to). Yokota, et al. Expires August 29, 2008 [Page 5] Internet-Draft Proxy-based Fast Handover February 2008 +----------+ | LMA | | | +----------+ / \ / \ / \ +........../..+ +..\..........+ . +-------+-+ .______. +-+-------+ . . | PAR |()_______)| NAR | . . | (PMAG) | . . | (NMAG) | . . +----+----+ . . +----+----+ . . | . . | . . ___|___ . . ___|___ . . / \ . . / \ . . ( P-AN ) . . ( N-AN ) . . \_______/ . . \_______/ . . | . . | . . +----+ . . +----+ . . | MN | ----------> | MN | . . +----+ . . +----+ . +.............+ +.............+ Figure 1: Reference network for fast handover Yokota, et al. Expires August 29, 2008 [Page 6] Internet-Draft Proxy-based Fast Handover February 2008 4. Proxy-based FMIPv6 Protocol Overview To reduce the handover latency due to signaling between the MAGs (Mobile Access Gateways) and the LMA (Local Mobility Anchor), FMIPv6 in this document specifies a bi-directional tunnel between the Previous MAG (PMAG) and the New MAG (NMAG). To expedite sending the Proxy Binding Update (PBU) by the NMAG, FMIPv6 protocol is also used for context transfer, whereby the necessary information for sending the PBU is 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. Since the MN is not directly involved with IP mobility, it is natural to think that the MN is not directly involved with fast handover procedures, either at least from the IP layer perspective. Therefore, among the messages for fast handovers defined in [3], those that are initiated by and targeted to the MN are not used when PMIPv6 is in use. Such messages are the Router Solicitation for Proxy Advertisement (RtSolPr), Proxy Router Advertisement (PrRtAdv), Fast Binding Update (FBU), Fast Binding Acknowledgment (FBack) and Unsolicited Neighbor Advertisement (UNA). 4.1. Protocol Operation FMIPv6 [3] specifies two types of fast handovers; the predictive fast handover and the reactive fast handover. In the predictive fast handover, the MN sends the FBU to the PAR before handover, which then triggers to establish a bi-directional tunnel between the PAR and NAR to transfer packets for the MN. On the other hand, in the reactive fast handover, the FBU is sent by the MN to the NAR after it has moved to the new network, which is then transferred to the PAR to trigger to send the Handover Initiate (HI) towards the NAR. Based on the above observations, the fast handover procedures for PMIPv6 need to work without the involvement of the MN. Figure 2 illustrates the predictive fast handover procedures for PMIPv6, where the bi- directional tunnel establishment is initiated by the PAR. Yokota, et al. Expires August 29, 2008 [Page 7] Internet-Draft Proxy-based Fast Handover February 2008 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-HoA,MN IID,LMA) | | | | | | | (d) | | | |<---HAck---| | | | | | (MN ID) | | | | | | | | | | | | HI/HAck | | (e) | | | |<--------->| | (f) | | | |==DL data=>| | | | | | | | (g) ~~~ | | | | | ~~~ | | | | | | MN-AN connection | AN-MAG connection | | (h) |<---establishment---->|<----establishment----->| | | | | (substitute for UNA) | | | | | | | | (i) |<==================DL data=====================| | | | | | | | (j) |===================UL data====================>|# | | | | #|<==========|# | | | | #|===================>| | | | | HI/HAck | | (k) | | | |<--------->| | / | | | | | | \ |(l) | | | | |--PBU-->| | | | | | | | | | |(m) | | | | |<--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. These IDs can be Link-Layer Addresses (LLAs) or any other types of IDs. This step is access technology specific. In some cases, the P-AN Yokota, et al. Expires August 29, 2008 [Page 8] Internet-Draft Proxy-based Fast Handover February 2008 will figure out which AP ID the MN is moving to. (b) The previous access network (P-AN), to which the MN is currently attached, indicates the handover of the MN to the PAR (PMAG). (c) The PAR sends the HI to the NAR. The HI message MUST include the MN ID and SHOULD include the MN-HoA, the MN-IID and the address of the LMA that is currently serving the MN. (d) The NAR sends back the Hack to the PAR. (e) The NAR requests the PAR to buffer or forward packets by setting U or F flags in the HI message, respectively. (f) If F flag is set in the HI at 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 detunneling, those packets may be buffered at the NAR. If the connection between the N-AN and NAR has already been established, those packet may reach the N-AN (access technology specific). (g) The MN hands over to the New Access Network (N-AN). (h) The MN establishes a connection (e.g. radio channel) with the N-AN, which in turn triggers the establishment of the connection between the N-AN and NAR if it has not been established, yet (access technology specific). This can be regarded as a substitute for the UNA. (i) The NAR starts to transfer 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 PAR MAY send the HI message to indicate that the packet forwarding is completed. (l) The NAR (NMAG) sends the Proxy Binding Update (PBU) to the LMA, whose address can be obtained in (c). Steps (l) and (m) are not part of the fast handover procedure, but shown for reference. (m) 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. Yokota, et al. Expires August 29, 2008 [Page 9] Internet-Draft Proxy-based Fast Handover February 2008 According to Section 4 of [3], 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, so the PAR transfers the packets for the MN to the NAR instead of the NCoA. The NAR then simply detunnels (decapsulates) those packets and delivers them to the MN. If the NAR obtains the LLA (=MN ID) and MN-HoA by the HI, it can create the NCE for the MN and deliver packets to it before the MN performs the ND. 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 [3]. 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: MN-HoA Outer source address: IP address of the PAR (PMAG) Outer destination address: IP address of the NAR (NMAG) In (i), Source address: MN-HoA Destination address: IP address of the CN In (j), - from the MN to the NMAG, Yokota, et al. Expires August 29, 2008 [Page 10] Internet-Draft Proxy-based Fast Handover February 2008 Source address: MN-HoA Destination address: IP address of the CN - from the NMAG to the PMAG, Inner source address: 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 LMA - from the PMAG to the LMA, Inner source address: 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 If the network that the MN has moved in 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 in steps (j) and (k). 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 step (c), the MN can retrieve it at or after step (g) by e.g. the authentication or DHCP procedure (not shown in the figure). 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 network. Figure 3 illustrates the reactive fast handover procedures for PMIPv6, where the bi-directional tunnel establishment is initiated by the NAR. Yokota, et al. Expires August 29, 2008 [Page 11] Internet-Draft Proxy-based Fast Handover February 2008 PMAG NMAG MN P-AN N-AN (PAR) (NAR) LMA | | | | | | (a) ~~~ | | | | | ~~~ | | | | | | MN-AN connection | AN-MAG connection | | (b) |<--establishment-->|<-------establishment------>| | | (MN ID) | (MN ID) | | | | |(substitute for UNA and FBU)| | | | | | | | | | | | HI | | (c) | | | |<---(MN ID) ---| | | | | | | | | | | | HAck | | (d) | | | |---(MN ID, --->| | | | | MN-HoA,MN IID,LMA) | | | | | | | (e) | | | |===DL data====>|# | |<====================DL data====================|# | | | | | | | (f) |=====================UL data===================>|# | | | | #=|<==============|# | | | | #=|=======================>| (g) | | | |<---HI/HAck--->| | | | | | | | / | | | | | | \ |(h) | | | | |--PBU-->| | | | | | | | | | |(i) | | | | |<--PBA--| | \ | | | | | | / Figure 3: Reactive fast handover for PMIPv6 (NAR initiated) The detailed descriptions are as follows: (a) The MN hands over from the P-AN to the N-AN. (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. This can be regarded as a substitute for the UNA and FBU. Yokota, et al. Expires August 29, 2008 [Page 12] Internet-Draft Proxy-based Fast Handover February 2008 (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 back the HAck to the NAR. The HAck message MUST include the 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 transferred from the PAR to the NAR over this tunnel. After detunneling, 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. (g) The PAR MAY send the HI message to indicate that the packet forwarding is completed. Steps (h)-(i) are the same as (l)-(m) 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. Also, in step (c), the NAR could send an unsolicited HAck message to the PAR, which then triggers the HI message from the PAR. By doing so, the directions of HI/HAck messages are aligned with the predictive (PAR-initiated) fast handover. Further study is needed if this call flow is more appropriate than the current one. 4.2. Handoff Type Considerations PMIPv6 [2] 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. According to [2], the following handoff types are defined: 0) Reserved 1) Attachment over a new interface Yokota, et al. Expires August 29, 2008 [Page 13] Internet-Draft Proxy-based Fast Handover February 2008 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 Identification (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. 4.3. IPv4 Support Considerations The motivation and usage scenarios of IPv4 protocol support by PMIPv6 are described in [5]. 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-MH-HoA to the NMAG, which is the inner destination address of the downlink forwarded packets. To this end, a new option called IPv4 Address Option is defined in this document. As for 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. The above IPv4 Address Option is defined so as to be able to convey IPv4-LMAA. The details of this option are described in Section 5.7. Yokota, et al. Expires August 29, 2008 [Page 14] Internet-Draft Proxy-based Fast Handover February 2008 5. Message Format This document extends the HI and HAck to work with PMIPv6 and further defines new options and option-codes for the IP Address option to convey context information. 5.1. Handover Initiate (HI) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------------------------------+ | Type | Code | Checksum | +---------------+-+-+-+-+-------+-------------------------------+ | Subtype |S|U|P|F|Resv'd | Identifier | +---------------+-+-+-+-+-------+-------------------------------+ | Options ... +------------------------- IP Fields: Source Address The IP address of PAR or NAR Destination Address The IP address of the peer AR All the other fields follow [3]. ICMP Fields: Code If P flag is not set, the Code value follows [3]. If P flag is set but F flag is not set, the Code MUST be set to zero. If both P flag and F flag are set, the Code value has the following meaning: 0, 1: See [3]. 2: Request forwarding 3: Indicate the completion of forwarding Yokota, et al. Expires August 29, 2008 [Page 15] Internet-Draft Proxy-based Fast Handover February 2008 S flag not used when P flag is set and MUST be set to zero. U flag Buffer flag. Same as [3]. P flag Proxy flag. When set, PMIPv6 instead of MIPv6 is assumed for the mobility management protocol. All the involved nodes MUST perform based on this document for fast handover procedures. F flag Forwarding flag. Used to request to forward the packets for the MN. All the other fields follow [3]. Valid options: MN ID This identifier can be the link-layer address of the MN or any other type of information that can uniquely identify the MN. If the link-layer address is used as the MN ID, the Link-Layer Address (LLA) option defined in [3] MUST be used. MN-HoA This information is stored in the IP Address option. MN-IID This information is stored in the MN Interface Identifier option. Context Request Option Context Request Option This option is used to request context information typically by the NAR to the PAR in the NAR-initiated fast handover. 5.2. Handover Acknowledge (HAck) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +--------------+--------------+--------------------------------+ | Type | Code | Checksum | +--------------+-+------------+--------------------------------+ | Subtype |P| Reserved | Identifier | +--------------+-+------------+--------------------------------+ | Options ... +------------------------ IP Fields: Yokota, et al. Expires August 29, 2008 [Page 16] Internet-Draft Proxy-based Fast Handover February 2008 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. All the other fields follow [3]. ICMP Fields: Code: 0: Handover Accepted 5: Context Transferred successfully, more context available 6: Context Transferred successfully, no more context available 128: Handover Not Accepted 129: Administratively prohibited 130: Insufficient resources 131: No context available 132: Forwarding Not Available P flag Proxy flag. When set, PMIPv6 instead of MIPv6 is assumed for the mobility management protocol. All the involved nodes MUST perform based on this document for fast handover procedures. Valid options: MN ID Copied from the corresponding HI message. Yokota, et al. Expires August 29, 2008 [Page 17] Internet-Draft Proxy-based Fast Handover February 2008 MN-HoA Stored in the IP Address option so that the NAR can use this address for the PBU. MN-IID This information is stored in the MN Interface Identifier option. LMA Stored in the IP Address option so that the NAR can use this address for the PBU. Requested option(s) All the other context information requested by the Context Request Option in the HI message. 5.3. Context Request Option This option is sent in the HI message to request context information on the MN. 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 | Reserved | +---------------------------------------------------------------+ | Reserved | +---------------+---------------+-------------------------------+ | Req-type-1 | Req-option-1 | Padding | +---------------------------------------------------------------+ | Padding | +---------------------------------------------------------------+ | ... | +---------------+---------------+-------------------------------+ | Req-type-N | Req-option-N | Vendor/Org-ID | +-------------------------------+-------------------------------+ | Vendor/Org-ID | VS-Type | +---------------------------------------------------------------+ | ... | 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, the requested option(s) MUST be included in the HAck message. Type TBD Length Number of requested context(s)+1. Yokota, et al. Expires August 29, 2008 [Page 18] Internet-Draft Proxy-based Fast Handover February 2008 Option-Code 0 Req-type-n The Type value for the requested option. Req-option-n The Option-Code for the requested option. Padding 6 octets of padding are added if the requested type is not the Vendor-Specific Option. MUST be set to zero. Vendor/Org-ID When the Vendor Specific Option is requested, the 3rd to 6th octets are used for the Vendor/Org-ID defined in Section 5.8. VS-Type When the Vendor Specific Option is requested, the 7th to 8th octets are used for the VS-Type defined in Section 5.8. 5.4. Tunnel-ID Option This option is used to transfer additional information that associates the MN with the tunnel used by the MN. The exact format of the Tunnel-ID is outside the scope of this document. 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 | TID-Length | +---------------------------------------------------------------+ | Tunnel-ID ... +------------------------------ Type TBD Length The size of this option is in 8 octets including the Type, Length and Option-Code. Option-Code 0 TID-Length The length of the Tunnel-ID in octets Tunnel-ID The Tunnel-ID value. 5.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 format of the interface identifier follows the Mobile Node Interface Identifier Option defined in [2]. Yokota, et al. Expires August 29, 2008 [Page 19] Internet-Draft Proxy-based Fast Handover February 2008 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 | MN IID-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Interface Identifier + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length The size of this option is in 8 octets including the Type, Length and Option-Code. Option-Code 0 MN IID-Length The length of the MN IID in octets Interface Identifier The Interface Identifier value of the MN that is used in the P-AN. 5.6. New option-code for the IP Address Option To convey the MN-HoA and LMA in the HI or HAck message, new Option- Codes for the IP Address Option[3] are defined: Option-Code 4 MN-HoA 5 LMA 5.7. 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). The IPv4 address of the LMA (IPv4-LMAA) is also needed to send PMIP signaling messages when the ARs and LMA are in an IPv4 transport network. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | Yokota, et al. Expires August 29, 2008 [Page 20] Internet-Draft Proxy-based Fast Handover February 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length 1 Option-Code 0 IPv4-MN-HoA 1 IPv4-LMAA IPv4 Address IPv4 address specified in Option-Code 5.8. Vendor Specific Option This option is to send other information than defined in this document. Many of the context information can be vendor specific (access technology specific). This option is used for such information. 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 | Reserved | +---------------------------------------------------------------+ | Vendor/Org-ID | +-------------------------------+-------------------------------+ | VS-Type | VS-Length | +---------------------------------------------------------------+ | VS-Value ... +------------------------------ Type TBD Length The size of this option is in 8 octets including the Type, Length and Option-Code. Option-Code 0 Vendor/Org-ID The SMI Network Management Private Enterprise Code of the Vendor/Organization as defined by IANA. VS-Type The type of the Vendor-Specific information carried in this option. The type value is defined by the vendor or organization specified by Vendor/Org-ID. Yokota, et al. Expires August 29, 2008 [Page 21] Internet-Draft Proxy-based Fast Handover February 2008 VS-Length The length of the Vendor-Specific information carried in this option. VS-Value The value of the Vendor-Specific information carried in this option. Yokota, et al. Expires August 29, 2008 [Page 22] Internet-Draft Proxy-based Fast Handover February 2008 6. Security Considerations Security issues for this document follow those for PMIPv6[2] and FMIPv6[3]. In this document, it is assumed that the PAR (PMAG), NAR (NMAG) and LMA have trust relationship with each other and the connection between any pair is securely protected. Yokota, et al. Expires August 29, 2008 [Page 23] Internet-Draft Proxy-based Fast Handover February 2008 7. References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Gundave, S., Ed., "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-10.txt, February 2008. [3] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", draft-ietf-mipshop-fmipv6-rfc4068bis-03.txt, October 2007. [4] Johnson, D., "Mobility Support in IPv6", RFC 3775, June 2004. 7.2. Informative References [5] Wakikawa, R., Ed. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-02.txt, November 2007. Yokota, et al. Expires August 29, 2008 [Page 24] Internet-Draft Proxy-based Fast Handover February 2008 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 Nokia Siemens Networks 313 Fairchild Drive Mountain View, CA 94043 US Email: rajeev.koodli@nsn.com Basavaraj Patil Nokia Siemens Networks 6000 Connection Drive Irving, TX 75039 US Email: basavaraj.patil@nsn.com Frank Xia Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 US Email: xiayangsong@huawei.com Yokota, et al. Expires August 29, 2008 [Page 25] Internet-Draft Proxy-based Fast Handover February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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). Yokota, et al. Expires August 29, 2008 [Page 26]