Internet Draft Fast Handover for HMIPv6 October 2005 Internet Draft HeeYoung Jung, ETRI Internet Engineering Task Force Hesham Soliman, Flarion draft-jung-mipshop-fhmipv6-00.txt SeokJoo Koh, KNU Expires April 2006 Noriaki Takamiya, NTT Software October 2005 Fast Handover for Hierarchical MIPv6 (F-HMIPv6) 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 Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document proposes a scheme to support Fast Handover over HMIPv6 networks. The HMIPv6 was developed to reduce the signaling overhead and delay concerned with Binding Update in Mobile IPv6. Therefore HMIPv6 still need a further handover enhancement for supporting the real-time applications. Currently FMIPv6 is the typical protocol to reduce the handover latency. Accordingly it may be straightforward to simply introduce FMIPv6 into HMIPv6 networks. However, it is noted that such simple approach may induce unnecessary processing overhead. F-HMIPv6, described in this document, considers how to integrate these two protocols and provides a scheme for effective integration. Jung, et al. Expires April 2006 [Page 1] Internet Draft Fast Handover for HMIPv6 October 2005 Table of Contents 1. Introduction..................................................3 2. Terminology...................................................3 3. Motivations...................................................4 4. Overview of F-HMIPv6..........................................5 4.1 Reference Architecture....................................5 4.2 Optimized data Flows in F-HMIPv6..........................6 5. F-HMIPv6 Operations...........................................7 5.1 Mobile-Initiated Handover.................................7 5.2 Network-Initiated Handover................................9 6. Considerations for F-HMIPv6 Implementations..................10 6.1 A New Flag in the HMIPv6 MAP Option......................11 6.2 Use of FMIPv6 messages in F-HMIPv6.......................11 6.3 AR-based RtSolPr/PrRtAdv.................................12 6.4 AR Information Message (ARInfoMsg).......................12 7. Variants of F-HMIPv6.........................................14 7.1 F-HMIPv6 with Bicasting..................................14 7.2 Reactive F-HMIPv6 without Anticipation...................15 7.3 Handover support between MAPs............................16 8. Security Considerations......................................16 9. References...................................................16 9.1 Normative References.....................................16 9.2 Informative References...................................16 Author's Addresses..............................................17 Full Copyright Statement........................................17 Intellectual Property...........................................17 Jung, et al. Expires April 2006 [Page 2] Internet Draft Fast Handover for HMIPv6 October 2005 1. Introduction The HMIPv6 [4] was developed to reduce the signaling overhead and delay concerned with Binding Update (BU) in Mobile IPv6 [3]. In HMIPv6, when a MN moves within a MAP region, the MN only sends a local BU to the local MAP, rather than the Home Agent (HA) and Correspondent Node (CN), as done in Mobile IPv6. If the distance from the MN to HA/CN is long, this local BU will considerably reduce the time required for the binding update. However, the HMIPv6 still need a further enhancement for supporting the real-time applications because HMIPv6 only concern with the latency due to BU and does not touch the latency related to Movement Detection and CoA configuration/Verification. Currently, the FMIPv6 [5] is the typical protocol that was designed to reduce the latency due to these two remaining issues. Therefore, if we want to support the fast handover scheme in HMIPv6 network, the simplest approach will be to apply the FMIPv6 to the HMIPv6 in the straightforward way. We describe in this document how to use FMIPv6 over HMIPv6 networks so as to provide better handover performance during handover. At a glance, it may be straightforward to simply integrate the FMIPv6 scheme with HMIPv6. However, such simple integration may induce unnecessary processing overhead for re-tunneling at the previous Access Routers and also inefficient usage of network bandwidth. The main reason for this is that the operation of HMIPv6 mainly depends on the functionality of a MAP, while the major functionalities of FMIPv6 are located in Access Routers (AR). This document describes a Fast Handover scheme for HMIPv6, named F- HMIPv6. In F-HMIPv6, the main operation for handover is accomplished by using MAP, rather than Access Router (i.e. PAR and NAR) like in FMIPv6. For this purpose, the MN exchanges the signaling messages for handover such as RtSolPr, PrRtAdv, FBU, and FBACK with MAP, not PAR. The F-HMIPv6 utilizes the FMIPv6 messages for handover support without further defining any new messages. For the use of F-HMIPv6, it is proposed to define a new flag 'F' in the HMIPv6 MAP option. 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 RFC 2119 [2]. This document uses all the terminology described in the MIPv6, HMIPv6, and FMIPv6 documents. In addition, this document uses the following terms for the on-link Care of Address (LCoA): Jung, et al. Expires April 2006 [Page 3] Internet Draft Fast Handover for HMIPv6 October 2005 PLCoA: MN's LCoA valid on the Previous Access Router (PAR). It corresponds to the PCoA of the FMIPv6. NLCoA: MN's LCoA valid on the New Access Router (NAR). It corresponds to the NCoA of the FMIPv6. 3. Motivations A natural and straightforward choice to combine FMIPv6 with HMIPv6 is to directly apply the FMIPv6 handover scheme in HMIPv6 networks, as they are specified. In this case, a bi-directional tunnel will be established between PAR and NAR via MAP by the FMIPv6 procedures. In this case, it may possibly induce inefficient signaling and data forwarding path. Figure 1 shows the data flow during handover by the simple integration of FMIPv6 with HMIPv6. CN PAR MAP MN(at NAR) | | | | | MIPv6 | | |---------------------->| | | | | | | | HMIPv6 | | | |<----------| | | | | | | | FMIPv6 | | |---------------------->| | | | | Figure 1: Data flows in the simple scheme According to the HMIPv6 operations, the data packets sent by CN will arrive at MAP and then be tunneled to MN over PLCoA. When the handover is initiated, a bi-directional tunnel will be established between PAR and NAR according to the FMIPv6 procedures. To forward the data packets to the NAR by using the tunnel, the PAR must first intercept those data packets flowing from the MAP, and then perform the re- tunneling process. This may be done by adding a new outer IP header of to the data packets sent by MAP according to the HMIPv6 operations. In the viewpoint of the HMIPv6 operations, the above straightforward approach has the following disadvantages: Jung, et al. Expires April 2006 [Page 4] Internet Draft Fast Handover for HMIPv6 October 2005 (1) The PAR must perform the tunneling operations for fast handover, in addition to the HMIPv6 tunneling from MAP to MN. To do this, the PAR must first intercept the data packets flowing from the MAP, which will be an additional overhead for HMIPv6. It is noted that the data delivery in HMIPv6 is performed based on MAP. (2) In HMIPv6, the actual data path of the bi-directional tunnel between PAR and NAR may include the MAP (i.e., PAR-MAP-NAR). Accordingly, the data packets will flow twice along the path between ARs and MAP. This induces inefficiency of network bandwidth usage, especially when ARs are connected to the network through bandwidth-limited links. (3) During handover, the possibility that the tunneled packets from PAR to NAR before F-BU arrive later at NAR than the packet sent directly from MAP by F-BU is relatively high. It will be the cause of the reversed sequence packets in NAR and the packets with reversed sequence makes TCP performance worse. (4) From such detouring feature, the overall handover latency and tunneling overhead may increase during the handover period. Moreover, it is likely to be difficult to exploit the advantages of FMIPv6 and HMIPv6 as well. (5) In hierarchical architecture like HMIPv6, the maintenance of information for neighbor ARs in each AR may be overhead. From the observations described above, it is clear that the fast handover for HMIPv6 needs to be designed by considering the data transport features of the HMIPv6 (i.e., in HMIPv6, all data packets are intercepted by MAP and delivered over the tunnel between MAP and MNs). 4. Overview of F-HMIPv6 4.1 Reference Architecture Figure 2 illustrates a reference configuration of the F-HMIPv6 network for fast handover support. In the figure, the MAP acts as an aggregation router in the hierarchical domain. When a mobile node (MN) enters a new HMIPv6 domain, firstly it performs the HMIPv6 registrations procedures with HA and MAP, as per MIPv6 and HMIPv6. Also, if the MN moves from a previous AR (PAR) to a new AR (NAR) within the domain, it will follow the Local Binding Update procedures of HMIPv6. At that time, if the fast handover is required for an on-going data session between MN and CN, then the F- HMIPv6 scheme will apply to the MN, ARs and MAP. Jung, et al. Expires April 2006 [Page 5] Internet Draft Fast Handover for HMIPv6 October 2005 +-------+ | HA | +-------+ | +----+ | | CN | | +----+ +-----+ | | +---+ | | +-------+ | MAP | RCoA +-------+ | | | +--------+ | | +-----+ +-----+ PLCoA | PAR | | NAR | NLCoA +-----+ +-----+ +----+ | MN | -------------> +----+ Movement Figure 2: Reference Architecture for F-HMIPv6 4.2 Optimized data Flows in F-HMIPv6 By the F-HMIPv6 scheme, the data packets sent by CN will be tunneled by the MAP toward the NAR during the handover. Figure 3 illustrates the data flows that F-HMIPv6 is willing to achieve. CN PAR MAP MN(at NAR) | | | | | MIPv6 | | | |---------------------->| | | | | | | | | F-HMIPv6 | | | |---------->| | | | | Figure 3: Optimized data flows by F-HMIPv6 Jung, et al. Expires April 2006 [Page 6] Internet Draft Fast Handover for HMIPv6 October 2005 Before handover, according to the HMIPv6 operations, the data packets sent by CN are tunneled by MAP to MN with the following IP fields: o Inner IP header: o Outer IP header: When the F-HMIPv6 handover is triggered (e.g., by receiving the FBU message from the MN), the MAP will establish a bi-directional tunnel with the NAR, and then begin to forward the data packets to the NAR over the tunnel. By the tunnel, each data packet has an additional outer IP header to the normal HMIPv6 headers with the following IP fields: o Additional outer IP header: When receiving the tunneled data packets from the MAP, the NAR will de-capsulate them and then be caching the decapsulated data packets. When the MN moves into the NAR region, the NAR will deliver the cached data packets to the MN, as done in FMIPv6. 5. F-HMIPv6 Operations In this section, we describe the generic F-HMIPv6 operations. It is assumed that the handover anticipation is supported with appropriate layer 2 triggers; and that the MNs as well as ARs are aware of the F- HMIPv6 scheme described in this document. The F-HMIPv6 procedures described in this section are based on the assumption that the MAP already has the information necessary for handover support about the ARs located in the HMIPv6 domain. It could be achieved by operators’ manual configuration, or with the help of a signaling operation between ARs and MAP, which will be described in Section 6.4. This information should include the link-layer address (or identifier) and network prefix of each AR. 5.1 Mobile-Initiated Handover Figure 4 illustrates the generic procedures for F-HMIPv6 operations. Jung, et al. Expires April 2006 [Page 7] Internet Draft Fast Handover for HMIPv6 October 2005 MN(at PAR) PAR MAP NAR MN(at NAR) | | | | | | HMIPv6 Data (before HO) | | | |<===========================>| | | | RtSolPr | | | | |---------------------------->| | | | PrRtAdv | | | | |<----------------------------| | | | FBU | | HI | | |---------------------------->|------------->| | | | | HACK | | | | |<-------------| | | | FBACK | FBACK | | | <-------------------|-------------------> | Disconnect | | | | | | |Packet Forward| | | | |=============>| | Connect | | Packet Delivery by FNA | | | |============>| | | Stop | LBU | | | Forwarding |<---------------------------| | | to NAR | LBACK | | | |--------------------------->| | | | HMIPv6 Data (after HO) | | | |<==========================>| | | | | | Figure 4: F-HMIPv6 for Mobile-Initiated Handover Note that the control messages depicted in Figure 4 have identical format to those in FMIPv6; only the contents (the IP source and destination fields) are different. These values are described more in details in Section 6. The detailed description for the control flows are given below: 1) Based on L2 handover anticipation, the MN sends RtSolPr message to MAP. The RtSolPr SHOULD include information about the link layer address or identifier of the concerned NAR. 2) In response to the RtSolPr message, the MAP sends the PrRtAdv message to the MN, which SHOULD contain information about NLCoA for the MN to use in the NAR region; i. e, NARs network prefix for stateless auto-configuration or NLCoA for stateful configuration. 3) Note in F-HMIPv6 that the MAP SHOULD already know the network prefix and link layer address of the associated NAR. Jung, et al. Expires April 2006 [Page 8] Internet Draft Fast Handover for HMIPv6 October 2005 4) The MN sends Fast Binding Update (FBU) message to MAP. The FBU message contains PLCoA and IP address of the NAR. 5) After receiving the FBU message from MN, the MAP will send a Handover Initiate (HI) message to the NAR so as to establish a bi-directional tunnel. In response to the HI message, the NAR will set up a host route entry for the MN's PLCoA and then respond with a Handover Acknowledge (HACK) message. As a result, a bi-directional tunnel between MAP and NAR will be established. Over the tunnel, the data packets sent by MAP have the additional outer IP header with the following IP fields of . The NAR may cache those data packets flowing from the MAP, until it receives the RS (possibly with FNA option) message from the newly incoming MN. 6) The MAP sends Fast Binding ACK (FBACK) messages toward the MN over PLCoA and NLCoA. Then, the MAP will begin to forward the data packets destined to MN to the NAR by using the established tunnel. 7) The MN sends FNA messages to NAR, when it detects that it is moved in the link layer, and receives the responding RA from the NAR. Then, the NAR delivers the buffered data packets to the MN over NLCoA. 8) The MN then follows the normal HMIPv6 operations by sending a Local Binding Update (LBU) to MAP, as per HMIPv6. When the MAP receives the new Local Binding Update with NLCoA from the MN, it will stop the packet forwarding to NAR and then clear the tunnel established for fast handover. 9) In response to LBU, the MAP sends Local Binding ACK (LBACK) to MN, and the remaining procedures will follow the HMIPv6. 5.2 Network-Initiated Handover This section describes the F-HMIPv6 operations for the network- initiated handover. In the network-initiated case, it is assumed that the PAR or NAR detects the movement of the MN from the PAR toward the NAR. Figure 5 illustrates the F-HMIPv6 operations for the network-initiated handover case. Jung, et al. Expires April 2006 [Page 9] Internet Draft Fast Handover for HMIPv6 October 2005 MN(at PAR) PAR MAP NAR MN(at NAR) | | | | | | | Trigger(ST) | Trigger(TT) | | | |~~~~~~~~~~~~~>|<~~~~~~~~~~~~~| | | | | | | | PrRtAdv | | | | |<----------------------------| | | | | | | | Figure 5: F-HMIPv6 for Network-Initiated Handover When the PAR receives a source trigger or the NAR receives a target trigger from the network, it sends a handover indication signal to the MAP, possibly via an out-of-band signaling. Such the signal SHOULD include information about the link layer address and PLCoA of the concerned MN as well as the link layer address or identifier of the associated NAR. When a network-initiated handover is indicated, the MAP sends the PrRtAdv message to the concerned MN. The PrRtAdv message SHOULD contain information about NLCoA for the MN to use in the NAR region. The remaining procedures are identical to those for the mobile- initiated handover case, as shown in Figure 4. 6. Considerations for F-HMIPv6 Implementations In this document, it is assumed that the MNs and ARs (including MAP) in the network are aware of the F-HMIPv6 described in this document as well as HMIPv6 [4]. For realizing the F-HMIPv6, the messages and functionality (e.g., triggers and tunnels) defined in FMIPv6 [5] will be used with slightly different procedures. The F-HMIPv6 is basically designed to exploit all the messages defined in FMIPv6 and HMIPv6 with the following exceptions: - A new flag is defined in the HMIPv6 MAP option, so as to indicate whether the MAP supports the F-HMIPv6 or not within the HMIPv6 domain. - Some of the FMIPv6 messages have different IP source and destination addresses in the respective IP fields. In particular, the MAP address is used instead of the PAR address. Jung, et al. Expires April 2006 [Page 10] Internet Draft Fast Handover for HMIPv6 October 2005 6.1 A New Flag in the HMIPv6 MAP Option Figure 6 shows the MAP option used for HMIPv6. A new flag 'F' is added for F-HMIPv6. When a MN moves into a new MAP domain, it receives the Router Advertisement with a MAP option from an access router. When the F bit is set in the MAP option, the MN MAY use F-HMIPv6. If the MN is not aware of F-HMIPv6, or the F bit is not set, it SHOULD NOT use F-HMIPv6. 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 | Dist | Pref |R|F| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Global IP Address for MAP + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: A new flag in the MAP option Fields: F When set indicates that the MAP support fast handover by F-HMIPv6. 6.2 Use of FMIPv6 messages in F-HMIPv6 F-HMIPv6 uses the messages for fast handover defined in FMIPv6, with different source and destination IP addresses. Table 1 summarizes the use of these messages. Jung, et al. Expires April 2006 [Page 11] Internet Draft Fast Handover for HMIPv6 October 2005 Table 1. Use of FMIPv6 Messages in F-HMIPv6 +--------------+-----------+-------------+---------------------+ | F-HMIPv6 | Source IP | Destination | Usage in FMIPv6 | | Messages | address | IP address | | +--------------+-----------+-------------+---------------------+ | RtSolPr | MN | MAP | Destination = PAR | |(Mobile-Ini.) | | | Source = MN | +--------------+-----------+-------------+---------------------+ | RtSolPr | PAR | MAP | Destination = PAR | |(Network-Ini.)| | | Source = MN | +--------------+-----------+-------------+---------------------+ | PrRtAdv | MAP | MN | Source = PAR | +--------------+-----------+-------------+---------------------+ | FBU | MN | MAP | Destination = PAR | +--------------+-----------+-------------+---------------------+ | FBACK | MAP | MN | Source = PAR | | | |(via PAR/NAR)| | +--------------+-----------+-------------+---------------------+ | HI | MAP | NAR | Source = PAR | +--------------+-----------+-------------+---------------------+ | HACK | NAR | MAP | Destination = PAR | +--------------+-----------+-------------+---------------------+ 6.3 AR-based RtSolPr/PrRtAdv F-HMIPv6 assumes that a MAP has all the necessary information about its serving ARs such as IP address and link layer ID, as seen in the conventional mobile networks hierarchically configured. In particular, if an access network supports the information sharing between ARs within its domain, the direct exchange of RtSolPr/PrRtAdv between an MN and an AR may be more effective. It is expected that the shorter signaling path can bring the lower latency. 6.4 AR Information Message (ARInfoMsg) As previously described, F-HMIPv6 assumes that a MAP has all the necessary information about its serving ARs such as IP address and link layer ID. It can be achieved by a certain signaling procedure between MAP and ARs specified by network operator. To facilitate this, a new ICMPv6 message could be defined, named 'AR Information Message (ARInfoMsg)' in this document. When each AR receives the MAP option with the flag 'F' set from the MN, it can send its link information to the MAP using the ARInfoMsg message. Jung, et al. Expires April 2006 [Page 12] Internet Draft Fast Handover for HMIPv6 October 2005 If the MAP receives an ARInfoMsg message from an AR, the MAP MAY store this information until the lifetime reaches to 0. This information can also be used by AR to send PrRtAdv to the MN. If the MAP can't recognize this message, this message is silently discarded. When the AR receives MAP option with 'F' flag set, it MAY send the ICMPv6 ARInfoMsg to the MAP in the following format. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... | +-+-+-+-+-+-+-+-+-+-+- Figure 7: ICMPv6 ARInfoMsg Message IP fields: Source Address The IP address of the AR, which is attached to the access network. Destination Address The IP address of the MAP. Type Code Preferred lifetime It is the same value of the preferred lifetime in the Router Advertisement message at the access network. Options AR can include the option defined in the 6.4.3 in [5]. The available options are the same as PrRtAdv: - New Access Point Link-Layer Address - New Router's Link-Layer Address - New Router Prefix Information option Jung, et al. Expires April 2006 [Page 13] Internet Draft Fast Handover for HMIPv6 October 2005 7. Variants of F-HMIPv6 7.1 F-HMIPv6 with Bicasting In this section as a variant of F-HMIPv6, the F-HMIPv6 with bicasting is considered. When a handover is indicated in the F-HMIPv6 domain, the MAP will provide the MN with the bicasting [6] toward both PAR and NAR. This variant could be applied to both mobile-initiated and network-initiated handover cases. The bicasting along with simultaneous binding [6] can be used to enhance the handover performance, in particular, for addressing the ping-pong effect. In F-HMIPv6, it is strongly recommended that the bicasting be used for stable handover. Figure 8 illustrates the F-HMIPv6 operations with bicasting. MN(at PAR) PAR MAP NAR MN(at NAR) | | | | | | HMIPv6 Data (before HO) | | | |<===========================>| | | | RtSolPr | | | | |---------------------------->| | | | PrRtAdv | | | | |<----------------------------| | | | FBU | | | |---------------------------->| | | | | FBACK | FBACK | | | <-------------------|-------------------> | Disconnect | | | | | | Begin Bicasting | | | |<=============|=============>| | Connect | | | | | | |Stop | | | | |Bicasting | FNA | | |<------------------------------------------| | | | | Forwarding | | | Forwarding | |============>| | |==========================================>| | | | | | | | | | | | | | LBU | | | |<---------------------------| | | | LBACK | | | |--------------------------->| | | | HMIPv6 Data (after HO) | | | |<==========================>| | | | | | Figure 8: F-HMIPv6 with Bicasting Jung, et al. Expires April 2006 [Page 14] Internet Draft Fast Handover for HMIPv6 October 2005 As shown in the figure, the basic control flows are identical to those for the generic F-HMIPv6 as described in Section 4, except that the bi-directional tunnel for handover is not used. On the other hand, the following rules for bicasting support apply to the basic F-HMIPv6 operations. 1) The PrRtAdv message sent by MAP SHOULD contain a valid NLCoA with the help of an appropriate NLCoA configuration scheme such as optimistic DAD [7] or stateful NLCoA configuration [8]. 2) The FBU message is used only for triggerring the bicasting by MAP. It is not concerned with the bi-directional tunnel establishment or HI/HACK messages. The FBACK message MAY be omitted. 3) The MAP begins the bicasting the data packets destined to MN (RcoA) via both PLCoA and NLCoA, as soon as it receives the FBU from the MN. 4) The MAP stops the bicasting when it receives the FNA message from MN via NAR. 5) The PAR and NAR forward the buffered packet to MN after receiving FNA message. Note in this scheme that a bi-directional tunnel between MAP and NAR is not established, as done in the normal HMIPv6. Note also that the HI/HACK messages are not used. For this purpose, this scheme assumes an appropriate CoA configuration scheme such as 'optimistic DAD' [7] or 'address pool based stateful NLCoA configuration' [8], to ensure that the NLCoA confirmation (via the DAD process) is not needed in the NAR. 7.2 Reactive F-HMIPv6 without Anticipation When the handover anticipation cannot be supported from the underlying link layer, the F-HMIPv6 will follow the normal HMIPv6 operation. The MN just sends the Local BU to MAP. In fact, the fast handover cannot be supported. As an option to recover the data packet loss by handover, when the MAP receives a new Local BU from the MN, it MAY request the corresponding PAR to forward the data packets (destined to the PLCoA and buffered by PAR until then) to the NLCoA. For this purpose, the PAR MAY have queued the data packets that were destined to the PLCoA of MN. Jung, et al. Expires April 2006 [Page 15] Internet Draft Fast Handover for HMIPv6 October 2005 7.3 Handover support between MAPs There may be the requirement of handover support for the MN moving to another MAP region. For supporting it, F-HMIPv6 may establish forwarding tunnel from old MAP to new MAP. The forwarding packets are buffered in new MAP and delivered to MN via an AR after new local BU. In this case, the handover latency may higher than it in case of the handover within a MAP. 8. Security Considerations The security issues of F-HMIPv6 are basically in line with those of FMIPv6 and HMIPv6. Note that the MN and MAP could have an IPsec security association in HMIPv6, thus the RtSolPr and PrRtAdv messages can also be protected with IPsec. This feature actually provides an advantage over FMIPv6 where ND messages cannot be secured in its present form. In addition, the MAP MUST ensure that the RtSolPr and FBU packets arrived from an MN that legitimately owns the RCoA. Otherwise, a bogus node could attempt to disrupt packets meant for the MN and redirect them to some access router. Further security issues will be identified, as the F-HMIPv6 work is progressing. 9. References 9.1 Normative References [1] S. Bradner, " Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. [2] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP, RFC 2119, March 1997. 9.2 Informative References [3] D. Johnson, et al., "Mobility Support in IPv6", RFC 3775, June 2004. [4] H. Soliman, et al., "Hierarchical Mobile IPv6 mobility management (HMIPv6)", RFC 4140, August 2005. [5] R. Koodli, et al., "Fast Handovers for Mobile IPv6", draftRFC 4068, July 2005. Jung, et al. Expires April 2006 [Page 16] Internet Draft Fast Handover for HMIPv6 October 2005 [6] K. ElMalki and H. Soliman, "Simultaneous Bindings for Mobile IPv6 Fast Handoffs", draft-elmalki-mobileip-bicasting-v6-03, June 2003. [7] N. Moore, "Optimistic Duplicate Address Detection for IPv6", draft-ietf-ipv6-optimistic-dad-05, February 2005. [8] H. Jung, et al., "Address Pool based Stateful NCoA Configuration for FMIPv6", draft-jung-mipshop-stateful-fmipv6-00, August 2003. Author's Addresses Hee Young Jung hyjung@etri.re.kr Protocol Engineering Center, ETRI Hesham Soliman H.Soliman@flarion.com Flarion Seok J. Koh sjkoh@knu.ac.kr Kyungpook National University Noriaki Takamiya takamiya@po.ntts.co.jp NTT Software Full Copyright Statement Copyright (C) The Internet Society (2005). 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 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 Jung, et al. Expires April 2006 [Page 17] Internet Draft Fast Handover for HMIPv6 October 2005 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. Jung, et al. Expires April 2006 [Page 18]