IETF MONAMI6 Working Group Jae Yong LEE Internet-Draft Byung Chul Kim Expires: January 5, 2008 Chungnam National University Hyun Seo Park Kyung Chul Shin ETRI July 2007 Fast Handovers for Multiple Interfaces Mobile IPv6 draft-jylee-monami6-fast-handoff-00.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 January 5, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document introduces extensions to Fast-handover Mobile IPv6 [6] that improves handover latency in Mobile IPv6 procedures in case mobile nodes have multiple wireless interfaces. In the basic Fast MIPv6 [6], the PAR (previous access router) forwards the arriving packets for the mobile node to the NAR (new access router) by setting Jae Yong LEE, et al. Expires January 5, 2008 [Page 1] Internet-Draft MFMIPv6 July 2007 up a tunnel to the NAR in order to prevent packet losses incurred by handover latency during handover procedure. Recently, many mobile nodes begin to have multiple wireless interfaces, and multiple active IPv6 Care-of-Addresses are assigned and registered simultaneously to a Home Agent [2] in order to utilize multiple wireless interfaces in terms of bandwidth, delay, etc. Furthermore, the Mobile IPv6 with extension to multiple CoA registration also needs fast handover procedure to reduce handover latency and packet losses. However, in the Mobile IPv6 with multiple CoA registration, packet tunneling to a NAR during handoff of one interface can incur performance degradation due to severe packet reordering when multiple interfaces are simultaneously used for load sharing. This is because the partial traffic flow coming from the interface involved in handover is suspended during handover and later tunneled to a NAR, while the other partial traffic flow is continuously forwarded to the mobile node through the other stable interface, which could incur severe reordering if the handover is delayed or unstable by ping-pong effects. We thus propose in this document an extension to Fast handover Mobile IPv6 procedure which can indicate a specific tunneling destination except the NAR, for example, other interfaces (or CoAs) in the same mobile node. This extension not only enhances the traffic quality during handoff but also improves the handover signaling performance because data traffic is redirected to another interface during handover signaling. Jae Yong LEE, et al. Expires January 5, 2008 [Page 2] Internet-Draft MFMIPv6 July 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 8 3.1. Protocol Procedure . . . . . . . . . . . . . . . . . . . 8 3.2. Mobile Node Operation . . . . . . . . . . . . . . . . . . 9 3.3. Access Router Operation . . . . . . . . . . . . . . . . . 10 4. Message Format Change . . . . . . . . . . . . . . . . . . . . 12 4.1 The Multi-interface Fast Binding Update (MFBU) message . . 12 4.2 Tunnel destination option . . . . . . . . . . . . . . . . 13 5. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . 21 Jae Yong LEE, et al. Expires January 5, 2008 [Page 3] Internet-Draft MFMIPv6 July 2007 1. Introduction Recently, in addition to the sharp increase of the mobile terminals, various kinds of wireless technologies are available for the mobile nodes. Mobile IPv6 [1] describes the protocol operations for a mobile node to maintain connectivity to the Internet during its handover from one access router to another. However, there is no wireless technology that guarantees always-on connectivity in mobile Internet. Therefore, a mobile node needs several wireless interfaces to maintain ubiquitous Internet connectivity. Recently, many mobile nodes begin to have multiple wireless interfaces and one wants to use them simultaneously to reinforce the connectivity to the Internet. However, the basic Mobile IPv6 protocol [1] cannot support the simultaneous usage of multiple interfaces, because the MIPv6 does not allow a mobile node to register multiple Care-of-Addresses (CoAs) corresponding to multiple attachments of several interfaces. As the multiple wireless technologies are available to a mobile node, they can be used for various purposes. An interface can be used as backup to recover from the possible loss of Internet connectivity of another interface. Two or more interfaces can be used simultaneously to increase the aggregate bandwidth, or load sharing. Different interfaces can be used for different applications according to their interface characteristics. When the mobility is involved, however, the current basic Mobile IPv6 [1] protocol is not adequate to support multiple CoAs concurrently. Recently, The multiple CoA registration protocol [2] extends the Mobile IPv6 protocol with an option called "Binding Unique Identifier (BID) sub-option" to associate multiple CoAs with one home address. There are also some documents discussing methods to bind a particular traffic flow to an appropriate CoA [3][4], and another documents supporting procedures for splitting a traffic flow and mapping to several CoAs to achieve load sharing [5]. Although the Mobile IPv6 protocol describes a procedure to maintain connectivity to the Internet during handover, the involved handover latency may degrade the quality of the Internet applications which are delay-sensitive or throughput-sensitive. In order to reduce the handover latency, the fast handover Mobile IPv6 (FMIPv6) protocol [6] has been proposed. This protocol tries to reduce the movement detection latency and new CoA configuration latency by processing the handover signaling in advance before detachment from the previous access router (PAR). In the basic Fast MIPv6 [6], the PAR forwards the arriving packets for the mobile node to the new access router (NAR) by setting up a tunnel to the NAR in order to prevent packet losses incurred by handover latency during handover procedure. For the same reason, it is necessary for the multiple interface Mobile IPv6 [2] protocol to adopt a fast handover procedure to Jae Yong LEE, et al. Expires January 5, 2008 [Page 4] Internet-Draft MFMIPv6 July 2007 packet losses. However, in the Mobile IPv6 using multiple CoA registration, packet tunneling to a NAR during handoff of one interface can incur performance degradation due to severe packet reordering when multiple interfaces are simultaneously used for load sharing. This is because the partial traffic flow destined to the interface involved in handover is suspended during handover and later tunneled to a NAR, but the mobile node may receive continuously the other partial traffic flow through another interfaces not involving handover. That could incur severe reordering if the handover procedure is delayed or unstable by ping-pong effects. In case the traffic is a TCP flow, this reordering severely degrades the throughput performance by turning on the TCP congestion control. This could also affect real-time applications. In contrast to the single interface FMIPv6, a multi-interface mobile node has a chance to have another active interface other than the interface involved in handover which can be used for tunneling destination. We thus propose in this document an extension to a multi-interface Fast handover Mobile IPv6 procedure which can indicate a specific tunneling destination except the NAR, for example, other interfaces (or CoAs) in the same mobile node. Then the severe reordering during handover procedure can be mitigated and the handover performance is enhanced. The throughput of a TCP flow would increase by avoiding unnecessary congestion control. Furthermore, this mechanism can improve the handover signaling performance because data traffic is redirected to another interface during handover signaling. After the successful handoff of the corresponding interface, the redirected traffic flow is restored to direct to the NAR and finally to the original interface. This specification considers a fast handover procedure for multi-interface MIPv6 in which multiple CoAs are registered. In this procedure, we propose a mobility option that indicates the tunnel destination point for the coming traffic flow to a PAR. The access routers (ARs) should recognize the tunnel destination option and redirect the traffic flow to another AR that is connected to another active interface of the same mobile node. There are no special requirements for a home agent to behave differently with respect to the basic FMIPv6 procedure. Jae Yong LEE, et al. Expires January 5, 2008 [Page 5] Internet-Draft MFMIPv6 July 2007 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 [1]. The following terminology and abbreviations are used in this document. The other terminology and abbreviations are to be used as described in Fast handover document RFC 4068 [6]. The reference handover scenario is illustrated in Figure 1. +----+ | HA | +--+-+ | | +---+------+ +----+ +-----+ Internet |----------+ CN | | +----------+ +----+ +--+--+ +---+--+ | AR1 +---------+router+-------+ +--+--+ +---+--+ | | | | | +--+--+ +--+--+ | | AR2 | | AR3 | If1 | +--+--+ +--+--+ | +--+--+ If2 | +-->+ MN +<------+ +--+--+ Movement ---------------> Figure 1: Reference Scenario for Multi-interface Handover In this reference scenario, we consider a mobile node having only two wireless interfaces for simplification. The AR1 is connected to the interface 1 of the mobile node and it is not involved in a handover at this time. The AR2 and AR3 are two access routers which are involved in a fast handover for the interface 2 of the mobile node. The AR2 is a PAR and the AR3 is a NAR for the interface 2. Handover interface: The wireless interface of the multi-interface mobile node that is currently involved in a handover procedure. Jae Yong LEE, et al. Expires January 5, 2008 [Page 6] Internet-Draft MFMIPv6 July 2007 Stable interface: The wireless interface of the multi-interface mobile node that currently maintains stable attachment to its access router and stable communication with it, that is, it does not involved in a handover at this moment. Tunnel destination option: One of mobility option introduced in this document to define the tunnel destination point to which traffic to the mobile node through the handover interface is directed when a multi-interface mobile node performs a fast handover. Usually, this option represents the CoA of other stable interface of the same mobile node. Multi-interface fast handover MIPv6 (MFMIPv6) protocol: The protocol procedure defined in this document in order to enhance the handover performance when a multi-interface mobile node that uses the multiple CoA registration procedure performs a fast handover. Jae Yong LEE, et al. Expires January 5, 2008 [Page 7] Internet-Draft MFMIPv6 July 2007 3. Protocol Operations 3.1. Protocol Procedure The protocol starts when an MN sends an RtSolPr (Router Solicitation for Proxy) to its access router through a handover-interface (e.g., interface 2 in Figure 1) to resolve one or more Access Point Identifiers to subnet-specific information. In response, the access router (e.g., AR2 in Figure 1) sends a PrRtAdv (Proxy Router Advertisement) message containing one or more access point ID and information. The MN may send a RtSolPr as a response to some link-specific event (a "trigger") or after performing router discovery. However, prior to sending RtSolPr, the MN should have discovered the available APs by link-specific methods such as AP scanning procedure in IEEE 802.11 wireless LAN. The RtSolPr and PrRtAdv messages do not establish any state at the access router. Their packet formats are defined in FMIPv6 [6]. With the information provided in the PrRtAdv message, the MN formulates a prospective NCoA (New CoA) and sends an FBU (Fast Binding Update) message. For a single interface FMIPv6, the main purpose of the FBU is to inform PAR of binding PCoA to NCoA, so that arriving packets can be tunneled to the new location of the MN. However, for a multi-interface FMIPv6, tunneling packets to NCoA may degrade the traffic performance by severe reordering as mentioned before. In this specification, we propose that the FBU message carries not only the NCoA but also a "tunnel destination" mobility option which could be another CoA that is registered for other interface of the same MN. We call this message as "Multi-interface Fast Binding Update (MFBU) message" to distinguish it from the FBU message of the basic FMIPv6 protocol. When the MN composes a MFBU message, it first checks the number of CoAs registered for multiple interfaces. Then, the MN selects candidate CoAs for tunnel destination which are not being involved in handover. Among them, the MN checks each interface whether or not it has appropriate characteristics for the traffic to be tunneled. The MN also examines the available bandwidth of candidate interfaces if they can accommodate the traffic. Finally, the CoA of the selected interface is inserted into the "tunnel destination" mobility option of the FBU message and the flag "T" is set to indicate the existence of the "tunnel destination" option. After the PAR receives the FBU message, the PAR begins tunneling packets arriving for PCoA to the "tunnel destination", in other words, to the CoA of another interface of the MN. Such a tunnel remains active until the MN completes the registration of a new CoA with its Home Agent or correspondents. In the reverse direction Jae Yong LEE, et al. Expires January 5, 2008 [Page 8] Internet-Draft MFMIPv6 July 2007 traffic, the MN SHOULD send packets through reverse tunnel to PAR through the interface of the 'tunnel destination' until the MN completes the Binding Update procedure of the NCoA. This is because such a reverse tunnel ensures that packets containing PCoA as a source IP address are not dropped due to ingress filtering. The format and semantics of the modified FBU message processing are specified in Section 4. After that, the HI (Handover Initiate), HACK (Handover Acknowledge), FBAck (Fast Binding Acknowledge) and FNA (Fast Network Attachment) messages are used in the protocol as the same way in the basic FMIPv6 protocol [6]. The overall scenario of multi-interface fast handover MIPv6 procedure is illustrated in Figure 2. Tunnel Dest. MN PAR NAR (another interface | | | of the same MN) |----- RtSolPr ------>| | | |<---- PrRtAdv -------| | | |----- MFBU --------->| | | | forward | | | packets ====================> | | | ----- HI ----->| | | | <--- HAck -----| | | <--FBack---|--FBack---> | | | | | | disconnect | | | | | | | | | | | connect | | | | | | | | --------- FNA ---------------------->| | | <=============================== deliver | | | new packets | Figure 2: Fast Handover for a Multi-interface MN 3.2. Mobile Node Operation The MN can send a RtSolPr message to find the subnet router information corresponding to nearby access points, when the MN gets an "L2 trigger" such as a fading signal quality and discovers one or more near access points. As a response to the RtSolPr message, the MN can receives the PrRtAdv message that contains the subnet information that indicates whether or not the discovered access points are Jae Yong LEE, et al. Expires January 5, 2008 [Page 9] Internet-Draft MFMIPv6 July 2007 connected the current PAR router or a new router to which the MN can be handed over. If the nearby access point is connected to a new router for handover and it provides the fast handover procedure, the MN SHOULD send the FBU message to the PAR whenever the handover is necessary to that NAR. At this point, the multi-interface MN using the procedure of this document SHOULD identify an active interface appropriate for the tunneling of the current traffic of the handover interface. Basically, the tunnel destination interface should not be currently involved in another handover. If a candidate interface has appropriate characteristics for the traffic to be tunneled and the its available bandwidth is enough to accommodate the tunneled traffic, the MN inserts the CoA of the corresponding interface into the "tunnel destination" mobility option of the FBU message and the "T" flag is set to 1. The detailed criterion to select an appropriate interface is over the scope of this document. Then, the handover interface is free from the data reception and it can concentrate on the handover signaling procedure because the traffic for that interface is tunneled to another interface of the MN by the PAR. If the MN has traffic to send to the CN, it SHOULD send packets through reverse tunnel to the PAR through the interface of the 'tunnel destination' option until it completes the handover in order to avoid the ingress filtering. If the MN does not support the protocol procedure of this document, the MN SHOULD follow the basic fast handover procedure. The MN expects a PrRtAdv in response to its RtSolPr message. If the MN does not receive a PrRtAdv message even after RTSOLPR-RETRIES, it must assume that PAR does not support the fast handover protocol and stop sending RtSolPr messages. Then, the MN follows the basic Mobile IPv6 procedure. 3.3. Access Router Operation As a response to the RtSolPr message, the PAR sends a PrRtAdv message to the MN in order to inform the MN of the connectivity conditions of the inquired access points. The RtSolPr message includes the query about whether or not the access points are connected to another new router other than the PAR and information of the new routers. When the handover is imminent, the PAR MAY receive the MFBU message from the MN containing the tunnel destination option and flag "T=1". It indicates that the MN wants to tunnel the corresponding interface traffic to the specified IP address in the tunnel destination option, not to the ordinary NAR. From this point, the PAR begins tunneling packets arriving for PCoA to the "tunnel destination", in other words, to the CoA of another interface of the MN. Such a tunnel remains active until the MN completes the Binding Update with its Jae Yong LEE, et al. Expires January 5, 2008 [Page 10] Internet-Draft MFMIPv6 July 2007 Home Agent or correspondents. As a response to the FBU, the PAR establishes a binding between PCoA and NCoA after exchanging the HI and HAck messages, and sends the FBack to the MN. Jae Yong LEE, et al. Expires January 5, 2008 [Page 11] Internet-Draft MFMIPv6 July 2007 4. Message Format Change The Mobile IPv6 uses a new IPv6 header type called Mobility Header as defined in [1]. For the procedure of this document, the Multi-interface Fast Binding Update that use the Mobility Header SHOULD be extended to include the required mobility option for tunneling traffic to another interface of the same MN. 4.1 The Multi-interface Fast Binding Update (MFBU) message The Multi-interface Fast Binding Update (MFBU) message is an extension to the FMIPv6 [6] FAST Binding Update (FBU) message. Two fields are added to the FBU message. One is the "tunnel destination" mobility option and "T" flag. The format of the MFBU message is illustrated in Figure 3. IP fields: Source Address The PCoA or NCoA Destination Address The IP address of the Previous Access Router A flag MUST be set to one to request that PAR send a Fast Binding Acknowledgment message. H flag Home Registration. MUST be set to one. See RFC 3775 [3]. L flag Link-Local Address Compatibility. See RFC 3775 [3]. Jae Yong LEE, et al. Expires January 5, 2008 [Page 12] Internet-Draft MFMIPv6 July 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|T| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . (Tunnel Destination option) . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Multi-interface Fast Binding Update (MFBU) Message K flag Key Management Mobility Capability See RFC 3775 [1]. T flag This flag indicates that the FBU message has a mobility option "tunnel destination". Reserved This field is unused. MUST be set zero. Sequence Number See RFC 3775 [1]. Lifetime See RFC 3775 [1]. Mobility Options MUST contain an alternate CoA option set to the NCoA when an FBU is sent from PAR's link. Tunnel destination option When the flag "T=1", the "tunnel destination" mobility option SHOULD be included. 4.2 Tunnel destination option The Tunnel Destination option SHOULD be included as a mobility option in the MFBU message in order to inform the PAR of the tunnel Jae Yong LEE, et al. Expires January 5, 2008 [Page 13] Internet-Draft MFMIPv6 July 2007 destination address to redirect traffic toward the handover interface of the MN to other interface CoA. This option is valid only in Multi-interface Fast Binding Update message. The format of the Tunnel Destination option is as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Tunnel Destination + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Tunnel Destination mobility option Type To be determined by IANA Length Length of an IPv6 address, 16 Tunnel Destination The CoA of an interface of the MN to which traffic to the handover interface is tunneled in multi-interface fast handover protocol. Jae Yong LEE, et al. Expires January 5, 2008 [Page 14] Internet-Draft MFMIPv6 July 2007 5. Usage Scenario In this section, we show a usage case of the tunnel destination option to illustrate how to use this option. We assume that a mobile node which is equipped with two wireless interfaces namely If1 and If2, is connected to different visited networks through two interfaces. The mobile node configures one global IPv6 address (Care-of-address) on each interface, namely CoA1 and CoA2 respectively. The mobile node runs Multi-interface Fast handover Mobile IPv6 (M-FMIPv6) protocol described in this document with a home agent located in its home network. The mobile node also runs multiple CoAs registration procedure defined in [2], and the two CoAs are registered to its Home Agent. The Home Agent (HA) utilizes the load sharing function by using the two different interfaces. For example, the HA evenly divides the incoming traffic for the MN and sends half of traffic to CoA1 and the other half to the CoA2. To do so, the mobile node may request its home agent to divide and redirect packets intended to the mobile node's home address to a different care-of address, depending on some conditions such as traffic load or traffic type. The mobile node may inform the HA of the weight of traffic division. We assume that the traffic to the MN is a TCP flow. We assume that the network topology is shown in Figure 1. The interface If2 is about to begin handover to AR3 from AR2. The first interface If1 is attached to AR1 and remains stable. If the mobile node runs the original fast handover Mobile IPv6 [6], the AR2 (PAR) begins buffering the traffic to the MN when it receives the FBU messages and tunneling to the NAR after the AR2 exchanges the HI and HAck messages. During this fast handover procedure, the half of traffic is continuously transferred to the MN through the other interface If1. This process MAY cause the severe packet reodering if the handover delay is large or traffic load is heavy. For example, we assume that the characteristics of two paths such as delay and bandwidth between the HA and two interfaces of the MN are similar, and the HA divides the traffic alternatively to If1 and If2 as follows. Jae Yong LEE, et al. Expires January 5, 2008 [Page 15] Internet-Draft MFMIPv6 July 2007 If1 (CoA1) : 1 3 5 7 9 11 13 15 ...... If2 (CoA2) : 2 4 6 8 10 12 14 ...... | |<- handover instant (FBU or MFBU message arrival to AR2) | |<- FNA message arrival to AR3 Figure 5 : Handover events in FMIPv6 or MFMIPv6 Then, the MN can receive in-order packets when the MN is not involved in handover. However, when the interface If2 starts handover and the MN runs the original fast handover procedure, the order of packet arrivals MAY become as follows if the MN's handover events occur as in Figure 5, 1 2 3 4 5 7 9 11 6 8 10 12 13 14 15 ...... Then, because we assume that the traffic is a TCP flow, the above reordering issues three duplicate ACKs when the MN receives packet 11. The corresponding node (CN) receives these 3 duplicate ACKs, takes this event as a packet loss and starts a congestion control procedure. So, the CN reduces its sending rate, which causes performance degradation. In contrast, when the MN runs the Multi-interface Fast handover Mobile IPv6 (M-FMIPv6) described in this document, the traffic toward If2 is redirected to CoA1 of interface If1 when the PAR receives the MFBU message that includes "tunnel destination" option equal to CoA1. Then, the order of packet arrivals MAY become as follows if the MN's handover events occur as in Figure 5, 1 2 3 4 5 7 9 6 11 8 13 10 15 12 14 ...... In this scenario, although the packet reordering could occur, three duplicate ACKs do not occur frequently because the CoA1 is not involved in handover at this moment and stable. Even if the handover latency of handover interface become very large, only one or two duplicate ACKs may occur. This event does not trigger the TCP congestion control in the CN because the TCP regards three or more duplicate ACKs as a packet loss. Thus, the congestion window does not decrease during handover and performance is not degraded. Jae Yong LEE, et al. Expires January 5, 2008 [Page 16] Internet-Draft MFMIPv6 July 2007 6. Security Considerations This draft introduces a new option called "tunnel destination" option that adds more information to the fast binding update (FBU) message. The new option allows the mobile node to redirect traffic flow of handover interface to another stable interface of the MN during fast handover. Since the tunnel destination option is a part of the mobility header, basically it can use the same security mechanism as the FBU message. However, since the tunnel destination option can optionally include a CoA of other stable interface of the same mobile node, it is pertinent for the receiver of the MFBU message to ensure that such address (if included) is in fact assigned to the mobile node. Hence, the PAR MUST ensure that the FBU packet arrived from a node that legitimately owns the CoA in tunnel destination option. The access router and its hosts may use any available mechanism to establish a security association that MUST be used to secure MFBU message. Future work will specify this security association establishment. Other security issue SHOULD follow the security mechanism of MIPv6 [1] and FMIPv6 [6]. Jae Yong LEE, et al. Expires January 5, 2008 [Page 17] Internet-Draft MFMIPv6 July 2007 7. IANA Considerations This document defines a mobility option called "tunnel destination" which requires a new number assignment for its type from IANA as shown in Figure 4. Jae Yong LEE, et al. Expires January 5, 2008 [Page 18] Internet-Draft MFMIPv6 July 2007 8. References [1] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [2] R. Wakikawa, T. Ernst, and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-00 (work in progress), June 2006. [3] H. Soliman, N. Montavont, N. Fikouras, K. Kuladinithi, "Flow binding in Mobile IPv6", draft-soliman-monami6-flow-binding-00 (work in progress), Febrary 2006. [4] C. Larsson, H. Levkowetz, H. Mahkonen, T. Kauppinen, "A Filter Rule Mechanism for Multi-access Mobile IPv6", draft-larsson-monami6-filter-rules-00 (work in progress), June 2006. [5] K. Kuladinithi, N.A. Fikouras, C. Goerg, K. Georgios, F. Pavlidou, "Filters for Mobile IPv6 Bindings (NOMADv6)", draft-nomadv6-mobileip-filters-03 Oct 2005. [6] R. Koodli, "Fast Handovers for Mobile IPv6" RFC 4068, July 2005. Jae Yong LEE, et al. Expires January 5, 2008 [Page 19] Internet-Draft MFMIPv6 July 2007 Authors' Addresses Jae Yong Lee Chungnam National University 220 Gung-dong, Yusung-ku, Daejeon 305-764 Korea Phone: +82-42-821-6865 Fax: +82-42-823-5586 Email: jyl@cnu.ac.kr Byung Chul Kim Chungnam National University 220 Gung-dong, Yusung-ku, Daejeon 305-764 Korea Phone: +82-42-821-6867 Fax: +82-42-823-5586 Email: byckim@cnu.ac.kr Hyun Seo Park ETRI 161 Gajeong-dong, Yuseong-gu, Daejeon 305-700 Korea Phone: +82-42-860-5312 Fax: +82-42-860-5119 Email: hspark@etri.re.kr Gyung Chul Sihn ETRI 161 Gajeong-dong, Yuseong-gu, Daejeon 305-700 Korea Phone: +82-42-860-6354 Fax: +82-42-860-5119 Email: neuro@etri.re.kr Jae Yong LEE, et al. Expires January 5, 2008 [Page 20] Internet-Draft MFMIPv6 July 2007 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jae Yong LEE, et al. Expires January 5, 2008 [Page 21]