IETF MIP6 Working Group N. Montavont Internet-Draft T. Noel Expires: January 16, 2006 LSIIT M. Kassi-Lahlou France Telecom R&D July 15, 2005 Mobile IPv6 for multiple interfaces (MMI) draft-montavont-mip6-mmi-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 January 16, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Mobile IPv6 [1] allows a MN to maintain its IPv6 communications while moving between subnets. This document presents the problematic for a MN that has multiple network interfaces. It discusses how to perform vertical handovers (flow redirection between interfaces) and propose MMI (Mobile IPv6 for Multiple Interfaces) which describes the use of Mobile IPv6 to support multiple interfaces. One one hand, these Montavont, et al. Expires January 16, 2006 [Page 1] Internet-Draft Mobile IPv6 for multiple interfaces July 2005 extensions focus on the MN ability to use a backup interface for communications and on the other hand to spread flows between the MN own interfaces. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology related to multiple interfaces . . . . . . . . . . 4 3. Motivations: Why a MN may want to redirect a flow . . . . . . 6 4. Multiple interfaces management . . . . . . . . . . . . . . . . 7 4.1 One home address per interface . . . . . . . . . . . . . . 7 4.2 Mechanism for redirection between interfaces . . . . . . . 7 4.3 Receiving new communications . . . . . . . . . . . . . . . 9 4.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Per-correspondant node mobility . . . . . . . . . . . . . . . 11 5.1 Spreading flows on interfaces . . . . . . . . . . . . . . 11 5.2 Create a new binding on a remote CN . . . . . . . . . . . 11 5.3 Several flows with the same CN . . . . . . . . . . . . . . 12 6. Per-flow Mobility . . . . . . . . . . . . . . . . . . . . . . 14 7. Load balancing Mobility . . . . . . . . . . . . . . . . . . . 16 7.1 Options of Binding Update . . . . . . . . . . . . . . . . 16 7.2 Binding Management . . . . . . . . . . . . . . . . . . . . 17 7.3 MN operations . . . . . . . . . . . . . . . . . . . . . . 17 7.3.1 Source careof address . . . . . . . . . . . . . . . . 18 7.3.2 Destination careof address . . . . . . . . . . . . . . 19 7.3.3 Security issues . . . . . . . . . . . . . . . . . . . 19 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . 23 Montavont, et al. Expires January 16, 2006 [Page 2] Internet-Draft Mobile IPv6 for multiple interfaces July 2005 1. Introduction Future MNs will probably have multiple interfaces to be connected to different access technologies. Thus a MN can benefit of the pros of each access technology to be connected everywhere at any time[2]. Each technology has its specific characteristics in terms of coverage area, bandwidth, reliability, etc. While Mobile IPv6 [1] allows a MN to handover between subnets, there are no requirements to manage mobility into the MN, i.e. between several interfaces. The document [3] lists the issues of Mobile IPv6 that prevent the use of multiple interfaces. This document presents the problematic of having multiple interfaces and proposes some simple extensions to Mobile IPv6, called MMI (Mobile IPv6 for Multiple Interfaces) to optimize the use of multiple interfaces. Assume a MN with two interfaces. At first, the MN can be connected to the network with only one interface. Then the MN moves away from the coverage area of its current point of attachment and looses its network connection through this interface. At the same time, it connects to the network with the other interface. Subsequently the MN may want all the flows using the first interface to be automatically redirected on the other available interface. In this case, the MN takes advantage of having multiple interfaces by using a backup interface. Another scenario would be a MN moving across different subnets, and use an alternative interface for its flows while it performs Mobile IPv6 operations. This would minimize the impact of the handover on the applications. In this document, the specific operations needed to perform vertical handovers are described. In the next section, some definitions related to multiple interfaces management are given. The section 3 explains why a MN may want to redirect flows between its interfaces. Then, MMI operations are described for a generic network configuration. These operations describe the use of Mobile IPv6 to perform vertical handovers. Then a per-correspondant node mobility is described, which is the ability for the MN to spread its flows on several interfaces with different CNs. Then we detail the per-flow mobility, the operations for the MN to independently manage each flow. Finally we describe the load balancing mobility, which allows the MN to use several CoAs and thus interfaces, for the same flow. We then conclude the document. Montavont, et al. Expires January 16, 2006 [Page 3] Internet-Draft Mobile IPv6 for multiple interfaces July 2005 2. Terminology related to multiple interfaces The following terms are introduced in the document. Some definitions are taken from [4]. Other definitions can be found in [2]. Available interface An interface that offers to the MN connectivity to the network. The interface is configured and attached to an AR. The MN can initiate and receive flows through this interface. L2 handover The change of point of attachement (link layer). L3 handover The change of IP subnet. Horizontal handover From the IP point of view, a horizontal handover happens if the MN changes of subnet it is connected to Vertical Handover (from [4]) In a vertical handover the MN's network interface to the access network changes. A vertical handover is typically an inter- technology handover. Previous interface During a vertical handover, the previous interface is the interface from which flow will be redirected. New interface During a vertical handover, the new interface is the interface to which flow will be redirected. Per-correspondant node mobility Per-CN mobility is the ability for the MN to indenpendatly manage flows from different CNs. Each CN is independently managed by the MN but all flows from a single CN are exchange via the same interface on the MN. Montavont, et al. Expires January 16, 2006 [Page 4] Internet-Draft Mobile IPv6 for multiple interfaces July 2005 Per-flow mobility The per-flow mobility is the ability for the MN to manage each flow independently. Each flow can be mapped to any interface, without disturbing other existing mappings between flows and interfaces. Per-flow Load balancing The per-flow load balancing is the ability for the MN to simultaneously use several interfaces with the same CN, even for the same flow. Montavont, et al. Expires January 16, 2006 [Page 5] Internet-Draft Mobile IPv6 for multiple interfaces July 2005 3. Motivations: Why a MN may want to redirect a flow When a MN has multiple interfaces, it may use its interfaces in many ways. It can keep a backup interface or uses them simultaneously. A MN may want to redirect its flows between its available interfaces for many reasons: o An interface in use comes down and thus does not offer network connectivity anymore. o The MN can take advantage of having multiple interfaces and redirects some or all flows from the down interface to another available interface o An interface comes up. The MN may decide that the interface which comes up is most suitable for its current flows currently using another interface o The MN performs a handover on an interface in use for flows. When a MN performs a horizontal handover, the handover latency (the time during which the MN can not send nor receive packets) can be long and then the quality of the flows can suffer. If the MN wants to minimize such perturbation, it can redirect some or all the flows on another available interface. This redirection can be done in advance of the handover if the L2 triggers are considered [5]. o The network capabilities change. The MN can observe a degradation of service on one of its interface, or conversely an improvement of capacity on an interface. The MN may then decide to redirect some or all flows on another interface that it considers most suitable for the target flows. o A new flow is initiated between the MN and a CN. According to internal policies, the MN may want to redirect this flow on a most suitable interface. Montavont, et al. Expires January 16, 2006 [Page 6] Internet-Draft Mobile IPv6 for multiple interfaces July 2005 4. Multiple interfaces management 4.1 One home address per interface In the following, we assume a MN with two interfaces I1 and I2 of different access technologies. Each interface is configured with a global IPv6 address, respectively IP1 and IP2. These two global IPv6 addresses are assigned to the MN in such a way that both addresses can be used to reach the MN. The MN uses Mobile IPv6 on each of its interfaces when it moves between subnets. The MN has a home link for each of its interfaces and there is a router acting as a home agent on each home link. The use of Mobile IPv6 to redirect flows between interfaces are highlighted for a generic network configuration. So IP1 and IP2 can be either home address or current CoA. 4.2 Mechanism for redirection between interfaces The mechanism for a MN to redirect flows from one of its interfaces (the previous interface) to another one (the new interface) is to perform a redirection between the IP address (previous IP address) allocated to the previous interface to the IP address (new IP address) allocated to the new interface. To do so, the MN sends a Binding Update through the new interface to register the IP address allocated to the new interface as new CoA for the redirected flows. To make things as clear as possible, this section discusses the flow redirection from (I1, IP1) to (I2, IP2), as illustrated in Figure 1. We also use HA1 to refer to the home agent used by the MN for its IP address IP1 and HA2 for the HA used by the MN for its IP address IP2. The operations are the same if IP1 (resp. IP2) is the home address or the current CoA allocated to I1 (resp. I2). Montavont, et al. Expires January 16, 2006 [Page 7] Internet-Draft Mobile IPv6 for multiple interfaces July 2005 Same or different access networks Home link or not. _________________......__________________ | | _| _| |_| AP1 |_| AP2 _____________ | | | \|/ Interface 1 (I1) \|/ \|/ Interface 2 (I2) IP1 | | IP2 |______| | | | MN | |______| To perform a vertical handover from the previous interface I1 to the new interface I2, the MN has to send a Binding Update to HA1 (and eventually to its CNs). The Binding Update must be sent as follow: o The home address field set to the IP address bound to the previous interface (IP1) o The CoA field set to the IP address bound to the new interface (IP2) This Binding Update must be sent through the new interface I2. This operation does not disturb the initial communications on the new interface I2 using IP2. But this may have an impact on the available bandwidth on I2. Thus, this mechanism allows a MN to send a binding information for a previous interface by using another interface, the new interface. Afterwards, if the MN moves to a new subnet through the new interface I2 (horizontal handover on I2), it obtains a new CoA (IP3). Besides the operations required in Mobile IPv6 when a MN changes its point of attachment, the MN has to send a Binding Update to HA2 (and eventually to CNs of its current flows which have a binding between IP1 and IP2 in their binding cache) to update its location. Now, the binding cache of HA1 records, among others, a binding between the home address IP1 and the CoA IP3. Thus, the movement detected on I2 is indicated to I1. Later, if the MN wants to use the previous interface I1 again and had registered an association on HA1 between IP1 and IP2, it needs to update the entry in the binding cache of HA1. If the MN is connected Montavont, et al. Expires January 16, 2006 [Page 8] Internet-Draft Mobile IPv6 for multiple interfaces July 2005 to a foreign network through the previous interface I1 (different from the home link), it sends a Binding Update with the new IPv6 address got on the current link as the new CoA. If the MN is connected to its home link through I1, it has to send a Binding Update to its home agent to make it invalid the binding cache for it (see returning home in [1]). 4.3 Receiving new communications No new mechanisms are required to receive a new communication once a redirection between interfaces was done. Consider a MN which has redirected flows from a previous interface (I1, IP1) to a new interface (I2, IP2) as described in this document (section 4.2). If the MN receives a new flow forwarded by HA1, the MN has several possibilities: it might reject the flow (e.g. the flow needs are not adapted to the network capacities provided to the MN); Or if the MN does not reject the flow, it might decide to inform the CN of the flow that its current address is IP2 and that it needs to use routing header [1]. 4.4 Discussion The use of multiple home addresses can be a solution to manage and optimize the use of several interfaces. If a MN can bind at least one home address per interface and can register a binding for each home address with a home agent (not necessarly the same), the use of Mobile IPv6 as described above allows a MN to spread its flows on several interfaces. When a MN initiates a new flow with a CN, it has to choose which (interface, home address) to use. To do so, the MN SHOULD keep a preference table indicating the prefered interface per type of flow and a default prefered interface (such as tables illustrated in Figure 2). Then, the choice of the interface determines the home address and thus the home agent to use for that flow. If the MN is connected to its home link through the chosen interface, then no mobile IPv6 operations are required. Otherwise, if the MN is away from its home link for this interface, it must have a binding on its home agent serving the target home address. If its home agent has not a binding for this home address, it must create one as defined in [1]. Then the MN may initiate a correspondant registration to perform route optimzation. If at any time, the MN wants to redirect a flow for which the MN uses the home address HoA1 to another interface, it has to send a Binding Update as described in section 4.2, with the current address of the new interface as CoA in the Binding Update. If all packets from CNs are encapsulated to the home agent (the CN has not a binding for the Montavont, et al. Expires January 16, 2006 [Page 9] Internet-Draft Mobile IPv6 for multiple interfaces July 2005 MN), all flows using the home address HoA1 will be redirected to the new interface. Otherwise, if the CN has a binding for the home address HoA1, the MN can send the Binding Update directly to the CN (after a return routability procedure). Therefore all flows with a single CN using the same home address and route optimization will use the same interface. The per-CN mobility is further detailed in next section. If the MN wants to use several interfaces with the same CN, it can initiate the flow with different home addresses. Montavont, et al. Expires January 16, 2006 [Page 10] Internet-Draft Mobile IPv6 for multiple interfaces July 2005 5. Per-correspondant node mobility While the previous section describes how a MN may use Mobile IPv6 when it has several interfaces, we will see in this section how a MN can use Mobile IPv6 to register different CoAs with different CNs to spread its flows from different CNs on different interfaces. 5.1 Spreading flows on interfaces When a CN exchanges data packets with a MN, it first uses the home address of the MN as source address in packets. Also, packets from CN are sent to the home address of the MN when it has no binding for the home address. If the MN is away from its home network for this home address and if the MN has already registered a primary CoA on the home agent (as defined in section 11.7.1 of [1]), the bi- directional tunnel between the home agent and the MN is used for all packets. Packets finally reach the interface on which the primary CoA of the MN is bound. In this situation, the MN may initiate a correspondant registration (return routability procedure and Binding Update / Binding Acknowledgment exchange) with that CN. The MN may register as well its primary CoA, as any other IPv6 address bound to one of its interfaces (even another home address). In order to manage the flow spreading on several interfaces, the MN may have a policy table to decide which interface(s) is (are) preferred for which type of flow. This policy table indicates for example that flow of type 1 should use interface 1 and flow of type 2 should use interface 2. But this policy table is made on the MN, and the MN can not know all its future CNs. So some policies can be not valid when the two flows are exchanged with the same CN; Current Mobile IPv6 specification does not allow to independently manage two flows with the same CN. Then the MN MUST choose which policy is the most important and redirect one of the two flows. This is what is called per-CN mobility. The choice of the interface will determine the choice of the CoA to register with the CN. 5.2 Create a new binding on a remote CN A MN MUST carefully choose which CoA to register with its CN. If the MN has several flows with the same CN, all flows MUST use the same CoA, i.e. the same interface. Therefore the MN has to maintain a policy table that do not generate conflicts. Figure 2 is an example of such a policy table. Montavont, et al. Expires January 16, 2006 [Page 11] Internet-Draft Mobile IPv6 for multiple interfaces July 2005 | Flow Disciminant | List of preferred interfaces | Priority |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|-+-+-+-+-+-+-+-+-+ |Default |if1 | x |1 |if3, if4 | 5 |5 |if2, if3 | 8 Figure 2. Interface preference This policy table shows preferences on interfaces according to a flow discriminant. The flow discriminant can be one, several or all fields of the source/destination ports numbers, source/destination address and protocol number. For example, it can be just a destination port, or the (source port, destination port, CN address) tuple. The priority field is used to set a priority on the different entries and helps in case of conflict (two different mappings with the same CN). When the MN wants to use route optimization with a CN, it first checks a policy table such as the one presented in Figure 2. This table gives to the MN the preferred interface for the flow. After having chosen the preferred interface, the MN MUST check its Binding Update List to find if the destination address of this flow has already an association between the MN home address and a CoA. If the destination address does not appear in the Binding Update List, the MN can initiate a correspondant registration with one of the address bound to the chosen interface. If the destination address is already in the Binding Update List, it means that the CN has already a binding for this home address. This case is discussed in the next subsection. 5.3 Several flows with the same CN The MN may also want to change a binding on a distant CN at any point of time, even if it does not get a new CoA. For example, its internal policies may change, or a new flow is initiated between the MN and the CN. We further detail the second case in this subsection. When a CN has a binding for a MN, all packets sent to the home address will be encapsulated to the registered CoA. If the CN initiates a new flow with the home address of the MN, packets will be tunneled to the registered CoA of the MN. This means that this new flow will reach the same interface as the previous flow of this CN. However, the internal preference of the MN may indicate that this flow would be better mapped to another interface of the MN, i.e. to another IPv6 address in most cases. In this case, the MN MUST be able to choose which rule to follow and then which CoA to register. The priority field of the table illustrated in Figure 2 can be used Montavont, et al. Expires January 16, 2006 [Page 12] Internet-Draft Mobile IPv6 for multiple interfaces July 2005 for this purpose. The most important flow determines the most prefered interface for the CN. The flow which has the higher priority will be picked to choose the new interface to use with that CN. If the most important flow indicates another interface than the one currently used with this CN, then the MN has to initiate a return routability procedure. Otherwise, nothing needs to be done, and the new flow will not use the prefered interface. Montavont, et al. Expires January 16, 2006 [Page 13] Internet-Draft Mobile IPv6 for multiple interfaces July 2005 6. Per-flow Mobility The per-flow mobility is a step more in the multiple interfaces management. The aim of this solution is to independently manage each flow, whatever the CN. Each flow can be uniquely identified and redirected between interfaces without modifying binding of other flows. Especially, flows exchanged with a single CN can be independently managed by registering a different CoA for each flow. To reach this goal, new options in Binding Update have to be defined in order to identify a flow and an entry in the binding cache since several CoAs would be bound to the same home address. On one hand, an ongoing flow between two hosts can be uniquely identified with the source/destination port numbers/addresses and the protocol number quintuplet. On the other hand, some types of flow use well-known port number(s). Also, for some application, the destination address is known, especially when it is a server, or the port number can be known, etc. A per-flow mobility should allow a MN to register different CoAs as well for established flows (where the quintuplet is known) as for future potential flows by using one or several fields of the quintuplet. Such solutions were already proposed at the IETF. The per-flow movement [6] proposes to use either the source/destination port numbers, source/destination addresses and protocol number quintuplet or the IPv6 flow label to identify a flow. In this solution, the full identifier of a flow must be included in the Binding Update sent by the MN to redirect a flow between two CoAs. However, it can be useful for the MN to set policies only for a subset of the quintuplet identifier, especially when the flow is not started yet. References [7] and [8] also propose new options to manage a per-flow mobility. Each option defined in these documents is used to identify a subset of a flow identifier such as a port number. When a MN sends a Binding Update with per-flow mobility option(s), the receiving CN may have several CoAs bound to the same home address. But in Mobile IPv6, the home address is the identifier of a binding. If the CN has several CoAs bound to the same home address, a new identifier is needed in the binding cache. Currently, two solutions are proposed to identify an entry in the binding cache: Reference [9] proposes a new field in Binding Update which is called Binding ID (BID). When the MN sends a Binding Update to a CN, it MAY includes a BID to uniquely identify this entry in the binding cache of the CN. So, when the MN wants to update an entry, it can identify which one with this BID. But, in the context of a per-flow mobility, the per-flow mobility option [6] already uniquely identifies an entry in the Binding cache. So it can be used to uniquely identify an entry in the CN binding cache. In this case, a Binding Update can Montavont, et al. Expires January 16, 2006 [Page 14] Internet-Draft Mobile IPv6 for multiple interfaces July 2005 include several per-flow mobility options. Montavont, et al. Expires January 16, 2006 [Page 15] Internet-Draft Mobile IPv6 for multiple interfaces July 2005 7. Load balancing Mobility The load balancing mobility is the finnest granular mobility that can be achieved on a multiple interfaces MN. This mechanism aims to allow a multiple interfaces MN to perform load balacing on several interfaces. The options defined in this section allow to use different interfaces to send and receive packets from one CN. Furthermore, this option can be used in addition of a per-flow mobility option (see previous section) to use several interfaces for the same flow. To do so, the MN can register different CoAs allocated to different interfaces for a single flow. 7.1 Options of Binding Update The following sub-option is proposed to register a CoA with policies for load balancing mobility. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Len | S | D | CoA ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Alternate Care-of address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. Load balancing mobility option Option Type TBD Option Len Length of option S Source address flag. When the Source address flag is set, the alternate advertised CoA will be one of the source CoA of packets sent to the CN. Montavont, et al. Expires January 16, 2006 [Page 16] Internet-Draft Mobile IPv6 for multiple interfaces July 2005 D Destination address flag. When the Destination address flag is set (different from 0), it means that the advertised CoA will be one of the destination address that the CN MUST use. When the flag is different from 1, it indicates the proportion of packets the CN has to send to the advetised CoA. Values for this field are to be defined, according to the authorized percentage. CoA ID Identifier of the CoA to be used in the binding cache in the receiving node. 0 is a reserved value that can be used for the source CoA of Binding Update (see next section). Alternate CoA The CoA to be registered on the receiving node. 7.2 Binding Management The binding cache in both HA and CN MUST be modified to support load balancing mobility. Binding cache MUST be extended to associate several CoAs to the same home address, in the same entry. Each CoA is identified by the CoA ID, received in load balancing mobility option. To choose between several CoAs in one entry, we also propose to associate two fields to each registered CoA: o Destination field: indicates if the corresponding CoA in the binding cache is used as destination address for the corresponding home address. A value different from 0 indicates the proportion of packets to be set with this CoA. o Source field: indicates that packets can be received with this CoA as source address. 7.3 MN operations A MN can use the load balacing mobility option in Binding Update sent to both its HA(s) and CN(s). A MN must take care which policy it assigns to a CoA that it registers with distant nodes, in order to keep distant node's binding cache coherent. When a MN is away from its home network and a distant node (HA of the MN or CN) has not yet a binding cache for this MN, the MN may send a Binding Update with the following content: Montavont, et al. Expires January 16, 2006 [Page 17] Internet-Draft Mobile IPv6 for multiple interfaces July 2005 o The MN may include more than one load balancing mobility option in the same Binding Update. o If the MN includes at least one load balancing mobility option, the source address of the Binding Update will also be registered by the distant node. The CoA ID of the source address of this Binding Update will be 0 (both in the Binding Cache of the receiving node and in the Binding Update list). o If the MN includes load balancing mobility option(s) only with the Destination flag set, the MN requests the distant node to send packets to a different CoA than the one(s) that the MN uses to send packets. The source address of the Binding Update will be registered as source CoA by the distant node. The CoA in the load balancing mobility option(s) must be registered as destination CoA, with the associated percentage. The CoA identifier is given by the CoA ID field of the option. o If the MN includes load balancing mobility option(s) only with the Source flag set, the MN requests the distant node to accept packets from the CoA(s) included in the load balancing mobility option(s). The source address of the Binding Update will be registered as destination CoA by the distant node. The CoA identifier is given by the CoA ID field of the option. o When a Binding Update includes different load balancing mobility options (some with the destination flag set and other(s) with the source address flag set), the source address of the Binding Update must be taken as a source CoA to register. When a MN is away from its home network and wants to update an existing entry in the Binding Cache of a distant node (HA of the MN or CN), the source address of the Binding Update will replace the source address with the CoA ID 0. If the MN had registered only one CoA without any load balancing mobility option, the source address of the Binding Update will replace the current registered CoA and will have the CoA ID 0. 7.3.1 Source careof address If the MN wants to use a specific CoA as source address in its outgoing packets, different from the CoA(s) that a distant node uses to send packets, it SHOULD send Binding Update with a load balancing mobility option with the source address flag set. The load balancing mobility option must be set as follows: o S = 1: Option indicates source CoA Montavont, et al. Expires January 16, 2006 [Page 18] Internet-Draft Mobile IPv6 for multiple interfaces July 2005 o D = 0 | integer (TBD): see subsection Section 7.3.2 o CoA ID = Identifier of the CoA set in the alternate CoA field. If this option updates an existing entry, this field must be set with the CoA ID that this option updates. o Alternate careof address: the new CoA the MN MAY use as source address to send data packets. 7.3.2 Destination careof address If the MN wants a distant node to send packets to a specific set of CoAs, the MN SHOULD send a Binding Update with a load balancing mobility option with the destination flag set. The option of the Binding Update MUST be filled as follows: o S = 0 | 1: see subsection Section 7.3.1 o D = integer (TBD) different from 0: indicates the proportion of packets sent by CN to the advertised alternate CoA. o CoA ID = identifier of the CoA set in the alternate CoA field. If this option updates an existing entry, this field must be set with the CoA ID that this option updates. o Alternate CoA: the new CoA the receiving node MUST use as destination address in packets sent to the corresponding home address. When a MN includes a destination load balancing mobility option in a Binding Update, care must be taken to register as much as CoA than those needed by the proportion. Upon reception of a Binding Update, the receiving node MUST have the right number of CoAs in order to respect the requested proportion. 7.3.3 Security issues The same security mechanisms as described in Mobile IPv6 MUST be performed when a MN sends a binding Update with a load balancing mobility option. When a MN sends a Binding Update with a load balancing mobility option to a CN, it has to initiate a return routability procedure for every CoAs the MN wants to register in the Binding Update (including the source address of the Binding Update). Montavont, et al. Expires January 16, 2006 [Page 19] Internet-Draft Mobile IPv6 for multiple interfaces July 2005 8. Conclusion Multihoming of MN is an important issue as described in [2]. When a MN has multiple interfaces, it is multihomed. We shown in this document that a multiple interfaces MN can be managed in different ways, through different granulary levels: per-CN mobility, per-flow mobility and load balancing mobility. Each solution brings different advantages to the MN and in some of them extensions to Mobile IPv6 are needed. The per-CN mobility allows a MN to use a different interface with different CNs. The advantage of this solution is that it only requires minor extensions to Mobile IPv6. The main drawback is when a MN has two flows with the same CN, the same interface has to be used. The per-flow mobility is the ability for the MN to manage each flow independently. This topic is already deeply investigated in individual propositions. The load balancing mobility allows a MN to use several interfaces with one CN or for one flow. A new option is introduced in this document to allow a MN to register several CoAs as source CoA or as destination CoA. Montavont, et al. Expires January 16, 2006 [Page 20] Internet-Draft Mobile IPv6 for multiple interfaces July 2005 9. Acknowledgements The authors would like to thank the members of the French RNRT Cyberte project (France Telecom RD, Cisco System, ENST Bretagne, IRISA, and LSIIT) for their valuable feedback. 10. References [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [2] Ernst, T., Montavont, N., Wakikawa, R., Paik, E., and K. Kuladinithi, "Goals and Benefits of Multihoming", I-D draft-ernst-generic-goals-and-benefits-01, February 2005. [3] Montavont, N., Wakikawa, R., Ernst, T., Ng, C-W., and K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", draft-montavont-mobileip-multihoming-pb-statement-04 (work in progress), June 2005. [4] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [5] Kempf, J., "Supporting Optimized Handover for IP Mobility - Requirements for Underlying Systems", I-D draft-manyfolks-l2-mobilereq-02.txt, June 2002. [6] Soliman, H., ElMalki, K., and C. Castelluccia, "Per-flow movement in MIPv6", I-D draft-soliman-mobileip-flow-move-03.txt, June 2003. [7] Montavont, N. and T. Noel, "Home Agent Filtering For Mobile IPv6", I-D draft-montavont-mobileip-ha-filtering-v6-00.txt, July 2003. [8] Koojana, K., Fikouras, N., Koensgen, A., and C. Goerg, "Filters for Mobile IPv6 Bindings (NOMADv6)", I-D draft-nomadv6-mobileip-filters-00.txt, July 2003. [9] Wakikawa, R., Uehara, K., Ernst, T., and K. Nagami, "Multiple careof address Registration on Mobile IPv6", I-D draft-wakikawa-mobileip-multiplecoa-03.txt, June 2005. [10] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [11] Ernst, T. and H-Y. Lach, "Network Mobility Support Montavont, et al. Expires January 16, 2006 [Page 21] Internet-Draft Mobile IPv6 for multiple interfaces July 2005 Terminology", I-D draft-ietf-nemo-terminology-03, February 2005. Montavont, et al. Expires January 16, 2006 [Page 22] Internet-Draft Mobile IPv6 for multiple interfaces July 2005 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 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 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Montavont, et al. Expires January 16, 2006 [Page 23]