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]