Internet Draft Hee Young Jung, ETRI Internet Engineering Task Force Seok Joo Koh, ETRI Expires February 2004 Hesham Soliman, Flarion August 2003 Jun Seob Lee, ETRI Karim El-Malki, Ericsson Bryan Hartwell, Consultant Fast Handover for Hierarchical MIPv6 (F-HMIPv6) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [1]. Internet-Drafts are 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 a "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. Abstract This document addresses Fast Handover over HMIPv6 networks. The MIPv6 mobility could be more enhanced by combining FMIPv6 with HMIPv6, in which MIPv6 is benefited from all the advantages of the respective schemes. An additional benefit by combining FMIPv6 with HMIPv6 is that the overall handover latency in FMIPv6 will be more reduced since in HMIPv6 the MN sends a location update with the local MAP, rather than the HA and CN that are typically further way. This document describes how to use FMIPv6 for HMIPv6 (F-HMIPv6). The F-HMIPv6 is designed to be friendly with the data transport feature of HMIPv6. In F-HMIPv6, the tunnel for fast handover is established between MAP and NAR, rather than between PAR and NAR. For this purpose, the MN exchanges the FMIPv6 messages with MAP, not PAR. The F-HMIPv6 utilizes the FMIPv6 messages for handover support without further defining any new messages. Two variants of F-HMIPv6 are also described: F-HMIPv6 with bicasting and Reactive F-HMIPv6 without handover anticipation. Jung, et al. [Page 1] INTERNET DRAFT Fast Handover for HMIPv6 August 2003 Table of Contents 1. Introduction..................................................3 2. Terminology...................................................4 3. Overview of F-HMIPv6..........................................4 3.1 Reference Architecture....................................4 3.2 Data Flows in F-HMIPv6....................................5 4. F-HMIPv6 Operations...........................................8 4.1 Mobile-Initiated Handover.................................8 4.2 Network-Initiated Handover...............................10 5. F-HMIPv6 Messages............................................11 5.1 A New Flag in the HMIPv6 MAP Option......................11 5.2 Use of FMIPv6 messages in F-HMIPv6.......................12 6. Variants of F-HMIPv6.........................................12 6.1 F-HMIPv6 with Bicasting..................................12 6.2 Reactive F-HMIPv6 without Anticipation...................14 7. Security Considerations......................................14 8. Acknowledgement..............................................15 9. References...................................................15 Author's Addresses..............................................16 Jung, et al. [Page 2] INTERNET DRAFT Fast Handover for HMIPv6 August 2003 1. Introduction The MIPv6 [3] could be benefited from its two extensional schemes: Hierarchical MIPv6 (HMIPv6) [4] and Fast Handover for MIPv6 (FMIPv6) [5]. Both the FMIPv6 and HMIPv6 have so far been designed in their own ways so as to enhance the MIPv6 in the signaling and handover aspects. The Hierarchical MIPv6 (HMIPv6) facilitates to reduce the signaling overhead and delay concerned with the location update, in which an MN sends a local Binding Updates (BU) to the local MAP, rather than the Home Agent (HA) and Correspondent Nodes (CN). On the other hand, the Fast Handover for MIPv6 (FMIPv6) uses bi-directional tunnels between ARs and exploits various L2 triggers for supporting fast handover and further minimizing service disruption during handover. This document addresses Fast Handover over HMIPv6 networks. It is noted that the MIPv6 mobility could be more enhanced by using the HMIPv6 and FMIPv6 together. By combining the FMIPv6 with HMIPv6, the MIPv6 could be benefited from all the advantages of the respective schemes; reduction of signaling delay and message overhead in HMIPv6, and also support of fast handover by L2 triggers and minimal service disruption by tunneling in FMIPv6. In particular, an additional benefit by combining FMIPv6 with HMIPv6 is that the overall handover latency in FMIPv6 will be more reduced. This is because in HMIPv6 the MN sends a location update only to the local MAP, rather than to HA and CN that are typically further away. Accordingly, the overhead to maintain the tunnels for handover will be also alleviated because the registration of a new CoA (NLCoA in HMIPv6) can be earlier completed. We describe in this document how to use FMIPv6 over HMIPv6 networks so as to provide better handover performance. 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 data transport of HMIPv6 is based on the tunneling from the MAP to MNs not ARs, while the FMIPv6 uses the tunneling between the previous and new Access Routers for fast handover. This document describes a Fast Handover scheme for HMIPv6, named F- HMIPv6. In F-HMIPv6, the tunnel for handover is established between MAP and NAR, rather than between PAR and NAR. 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. Jung, et al. [Page 3] INTERNET DRAFT Fast Handover for HMIPv6 August 2003 We also discuss two variants of the above mentioned F-HMIPv6 scheme; (1) F-HMIPv6 with bicasting, in which the MAP performs bicasting to PLCoA and NLCoA in response to the handover indication; (2) Reactive F-HMIPv6 without anticipation from the underlying link layer. 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): 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. Overview of F-HMIPv6 3.1 Reference Architecture This document addresses how to support fast handover in HMIPv6 networks. For this purpose, 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. Figure 1 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, 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. [Page 4] INTERNET DRAFT Fast Handover for HMIPv6 August 2003 +-------+ | HA | +-------+ | +----+ | | CN | | +----+ +-----+ | | +---+ | | +-------+ | MAP | RCoA +-------+ | | | +--------+ | | +-----+ +-----+ PLCoA | PAR | | NAR | NLCoA +-----+ +-----+ +----+ | MN | -------------> +----+ Movement Figure 1: Reference Architecture for F-HMIPv6 3.2 Data Flows in F-HMIPv6 It is clear that a combination of FMIPv6 and HMIPv6 gives the harmonized benefits in terms of signaling overhead and latency (by HMIPv6) as well as fast handover (by FMIPv6). 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 by the FMIPv6 procedures. However, simply integrating FMIPv6 with HMIPv6 may possibly induce additional processing overhead for re-tunneling at PAR, as well as inefficient usage of network bandwidth. Figure 2 shows the data flow by the simple integration of FMIPv6 with HMIPv6. According to the HMIPv6 operations, the data packets sent by CN will arrive at MAP and then be tunneled to MN over PLCoA. Jung, et al. [Page 5] INTERNET DRAFT Fast Handover for HMIPv6 August 2003 CN PAR MAP MN(at NAR) | | | | | MIPv6 | | |---------------------->| | | | | | | | HMIPv6 | | | |<----------| | | | | | | | FMIPv6 | | |---------------------->| | | | | Figure 2: Data flows by FMIPv6 in HMIPv6 networks 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: (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 PAR and MAP. This induces inefficiency of network bandwidth usage, especially when ARs are connected to the network through bandwidth-limited links. (3) In this scheme, a handover event of MN to NAR cannot be informed to MAP, despite that the HMIPv6 data channel to NLCoA must be established by MAP, after the MN moves to the NAR region. Accordingly, the benefits of handover anticipation will be depreciated in this approach. (4) From such detouring feature, the overall handover latency and tunneling overhead may increase during the handover period. Jung, et al. [Page 6] INTERNET DRAFT Fast Handover for HMIPv6 August 2003 Moreover, it is likely to be difficult to exploit the advantages of FMIPv6 and HMIPv6 as well. 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). This document describes Fast Handover for HMIPv6 (F-HMIPv6), in which the MAP performs the tunneling for fast handover instead of the PAR. 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 by the F-HMIPv6. CN PAR MAP MN(at NAR) | | | | | MIPv6 | | | |---------------------->| | | | | | | | | F-HMIPv6 | | | |---------->| | | | | Figure 3: Data flows by F-HMIPv6 during handover 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. Jung, et al. [Page 7] INTERNET DRAFT Fast Handover for HMIPv6 August 2003 4. F-HMIPv6 Operations In this section, we describe the generic F-HMIPv6 operations for the mobile-initiated and network-initiated handover cases. It is assumed that the handover anticipation is supported with appropriate layer 2 triggers; and that the MNs as well ass 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. This information should include the link-layer address (or identifier) and network prefix of each AR. 4.1 Mobile-Initiated Handover In this section, we describe the F-HMIPv6 operations for the mobile- initiated handover. Figure 4 illustrates the generic procedures for F-HMIPv6 operations. 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 RS/RA | | | |============>| | | Stop | LBU | | | Forwarding |<---------------------------| | | to NAR | LBACK | | | |--------------------------->| | | | HMIPv6 Data (after HO) | | | |<==========================>| | | | | | Figure 4: F-HMIPv6 for Mobile-Initiated Handover Jung, et al. [Page 8] INTERNET DRAFT Fast Handover for HMIPv6 August 2003 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 5. 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. Note in F-HMIPv6 that the MAP SHOULD already know the network prefix and link layer address of the associated NAR. 3) The MN sends Fast Binding Update (FBU) message to MAP. The FBU message contains PLCoA and IP address of the NAR. 4) 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. 5) 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. 6) The MN exchanges the RS and RA messages with 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. Jung, et al. [Page 9] INTERNET DRAFT Fast Handover for HMIPv6 August 2003 7) 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. 8) In response to LBU, the MAP sends Local Binding ACK (LBACK) to MN, and the remaining procedures will follow the HMIPv6. 4.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. 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. Jung, et al. [Page 10] INTERNET DRAFT Fast Handover for HMIPv6 August 2003 5. F-HMIPv6 Messages The F-HMIPv6 is 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. 5.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 set in the MAP option indicates that the mobile node 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|I|P|V|F| Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. Jung, et al. [Page 11] INTERNET DRAFT Fast Handover for HMIPv6 August 2003 5.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. 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. Variants of F-HMIPv6 6.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. 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 Jung, et al. [Page 12] INTERNET DRAFT Fast Handover for HMIPv6 August 2003 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. Figure 7 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 | LBU | | | Bicasting |<---------------------------| | | | LBACK | | | |--------------------------->| | | | HMIPv6 Data (after HO) | | | |<==========================>| | | | | | Figure 7: F-HMIPv6 with Bicasting 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. Jung, et al. [Page 13] INTERNET DRAFT Fast Handover for HMIPv6 August 2003 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 normal LBU message from MN. By implementation, the MN MAY send the LBU message when it is in the PAR region. 6.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. 7. 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. Jung, et al. [Page 14] INTERNET DRAFT Fast Handover for HMIPv6 August 2003 8. Acknowledgement The Authors would like to give special thanks to the following people for their valuable comments and discussion for enhancing the F-HMIPv6. Greg Daley (Monash) Sung Han Kim (ETRI) Byung Jin Lee (Ajou University) Eva Gustafsson (Ericsson) 9. References [1] S. Bradner, "The Internet Standards Process -- Revision 3", BCP, RFC 2026, October 1996. [2] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP, RFC 2119, March 1997. [3] D. Johnson, et al., "Mobility Support in IPv6", draft-ietf- mobileip-ipv6-24, June 2003. [4] H. Soliman, et al., "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft-ietf-mobileip-hmipv6-08, June 2003. [5] R. Koodli, et al., "Fast Handovers for Mobile IPv6", draft-ietf- mobileip-fast-mipv6-06, March 2003. [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", draft-moore- ipv6-optimistic-dad-02, February 2003. [8] H. Jung, et al., "Address Pool based Stateful NCoA Configuration for FMIPv6", draft-jung-mipshop-stateful-fmipv6-00, August 2003. Jung, et al. [Page 15] INTERNET DRAFT Fast Handover for HMIPv6 August 2003 Author's Addresses Hee Young Jung hyjung@etri.re.kr Protocol Engineering Center, ETRI Seok Joo Koh sjkoh@etri.re.kr Protocol Engineering Center, ETRI Hesham Soliman H.Soliman@flarion.com Flarion Jun Seob Lee juns@etri.re.kr Protocol Engineering Center, ETRI Karim El Malki Karim.El-Malki@era.ericsson.se Ericsson Radio Systems AB Bryan Hartwell bryan@ashnet.com Jung, et al. [Page 16]