IETF MONAMI6 Working Group N. Montavont
Internet-Draft ENST-B
Expires: April 30, 2006 R. Wakikawa
Keio University
T. Ernst
Keio University / WIDE
C. Ng
Panasonic Singapore Labs
K. Kuladinithi
University of Bremen
October 27, 2005
Analysis of Multihoming in Mobile IPv6
draft-montavont-mobileip-multihoming-pb-statement-05.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 April 30, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The use of multiple interfaces is foreseen to provide ubiquitous,
Montavont, et al. Expires April 30, 2006 [Page 1]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
permanent and fault-tolerant access to the Internet, particularly on
mobile nodes which are more prone to failure or sudden lack of
connectivity. However, Mobile IPv6 currently lacks support for such
multihomed nodes. Individual solutions have been proposed to extend
Mobile IPv6 but all issues have not been addressed in a single
document. The purpose of the present document is thus to fill up
this gap and to raise the discussion in order to make sure that
forthcoming solutions will address all the issues. In this document,
we propose a taxonomy to classify the situations where a mobile node
could be multihomed. This taxonomy is then used to highlight the
issues preventing mobile nodes operating Mobile IPv6 to be
multihomed.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. (1,1): 1 HoA, 1 CoA . . . . . . . . . . . . . . . . . . . 12
5.2. (n,1): n HoAs, 1 CoA . . . . . . . . . . . . . . . . . . . 13
5.3. (1,n): 1 HoA, n CoAs . . . . . . . . . . . . . . . . . . . 15
5.4. (n,n): n HoAs, n CoAs . . . . . . . . . . . . . . . . . . 15
5.5. (n,0): n HoAs, no CoAs . . . . . . . . . . . . . . . . . . 16
6. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. General IPv6-related Issues . . . . . . . . . . . . . . . 18
6.1.1. Path Selection . . . . . . . . . . . . . . . . . . . . 18
6.1.2. Ingress Filtering . . . . . . . . . . . . . . . . . . 19
6.1.3. Failure detection . . . . . . . . . . . . . . . . . . 20
6.2. MIPv6-specific Issues . . . . . . . . . . . . . . . . . . 20
6.2.1. Binding Multiple CoAs to a given HoA . . . . . . . . . 20
6.2.2. Using one HoA as a CoA . . . . . . . . . . . . . . . . 21
6.2.3. Simultaneous location in home and foreign networks . . 22
6.3. Considerations for MIPv6 Implementation . . . . . . . . . 22
6.3.1. Binding a new CoA to the right HoA . . . . . . . . . . 22
6.3.2. Binding HoA to interface . . . . . . . . . . . . . . . 22
6.3.3. Flow redirection . . . . . . . . . . . . . . . . . . . 23
6.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 24
7. TODO List . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Montavont, et al. Expires April 30, 2006 [Page 2]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Appendix A. Why a MN may want to redirect flows . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 33
Montavont, et al. Expires April 30, 2006 [Page 3]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
1. Introduction
The use of multiple addresses (allocated to either a single interface
or multiple interfaces) is foreseen to provide ubiquitous, permanent
and fault-tolerant access to the Internet, particularly on mobile
nodes which are prone to failure or sudden lack of connectivity.
Mobile IPv6 [1],[2] is designed to allow a mobile node to maintain
its IPv6 communications while moving between IPv6 subnets. However,
the current specification of Mobile IPv6 lacks support for mobile
nodes with multiple addresses used simultaneously, i.e. multihomed
mobile nodes. These addresses would be assigned to a single
interface or to multiple interfaces, which poses a number of issues.
Individual solutions have been proposed to extend Mobile IPv6 for
multihomed mobile nodes, but all issues have not been addressed in a
single document. The purpose of the present document is thus to fill
up this gap by listing such issues, raising the discussion at the
IETF, and placing some requirements in order to propose comprehensive
solutions in forthcoming standards.
This document has two goals. The first goal of this document is to
define the requirements from the point of view of multihomed mobile
nodes operating Mobile IPv6. The second goal of this document is to
define the issues arising when we attempt to fulfill these
requirements. The definition of the potentially needed solutions is
out of scope of the analysis document. These should be defined in a
separate document once the IETF community agrees on which issues
should be solved.
In order to reach the goals of this document, we define a taxonomy
which is used to describe the different situations where a mobile
node is multihomed. For each case, we show the configuration a
multihomed node may have (number of interfaces, number of Home
Addresses or number of Care-of Addresses). We also illustrate each
scenario.
To understand the foundation of this document, the reader must read
our companion document [3] which outlines the motivations, the goals
and the benefits of multihoming for both fixed and mobile nodes (i.e.
generic IPv6 nodes). Real-life scenarios as illustrated in that
document are the base motivations of the present study. The reader
must also understand the operation of the Mobile IPv6 protocol ([1]).
The document is organized as follows: in Section 2, we introduce the
terminology related to multihoming and used in this document. In
Section 3, we discuss what is required on the mobile nodes to fully
benefit from a multihomed configuration. Then we propose in
Section 4 a taxonomy to classify the different cases where mobile
Montavont, et al. Expires April 30, 2006 [Page 4]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
nodes are multihomed. Thereafter the taxonomy is used in Section 5
to describe a number of multihomed configuration specific to Mobile
IPv6. Finally we discuss in Section 6 and Section 6.3 all issues
related to a multihomed MN and we identify what is missing to reach
the goals outlined in [3]. These issues are classified into IPv6
issues, Mobile IPv6-specific issues, and advices to implementers.
Montavont, et al. Expires April 30, 2006 [Page 5]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
2. Terminology
The terms used in the present document are defined in [4], [1] and
[3].
In this draft we are using the following terms and abbreviations:
o MIPv6
The Mobile IPv6 protocol specified in [1]
o MN
a Mobile Node operating MIPv6
o HA
a Home Agent
o HoA
Home Address
o CoA
Care-of Address
o Multihomed MN
In [3], a node is said to be multihomed when it has multiple IPv6
addresses, either because multiple prefixes are advertised on the
link(s) the node is attached to, or because the node has multiple
interfaces (see the entire definition). For a mobile node
operating MIPv6, this may translate into the following definition:
A MN operating MIPv6 is said multihomed when it simultaneously has
(i) multiple HoAs; (ii) multiple CoAs; and/or (iii) one HoA and
one CoA configured on different interfaces. A MN may have
multiple HoAs/CoAs in the following cases:
* A MN would have multiple HoAs if multiple prefixes are
available on the home link or if it has multiple interfaces
named on (presumably) distinct home links.
* A MN would have multiple CoAs if multiple prefixes are
available on the foreign link or if it has multiple interfaces
attached to (presumably) distinct foreign links.
Montavont, et al. Expires April 30, 2006 [Page 6]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
o A valid address
An address that is topologically correct (it is named after the
prefix available on the link the interface is attached to) and
routable.
o Simultaneously using multiple addresses
This indicates a scenario where the MN has the ability to use any
of the said multiple addresses at the same time. This implies
that a packet with the destination field set to one of the said
multiple addresses will reach the MN, either directly from a CN to
the MN or through a tunnel with one of the MN's HAs. This also
implies that any of the said multiple addresses can be used as
source address above the MIPv6 layer.
o Simultaneously using multiple interfaces
This indicates a scenario when there is at least one valid address
named for each of the said multiple interfaces, and that the MN is
able to simultaneously use these addresses.
Montavont, et al. Expires April 30, 2006 [Page 7]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
3. Requirements
The following generic goals and benefits of multihoming are discussed
in the companion document [3]:
1. Permanent and Ubiquitous Access
2. Reliability
3. Load Sharing
4. Load Balancing/Flow Distribution
5. Preference Settings
6. Aggregate Bandwidth
In this section, we are determining what is required for a mobile
node to achieve these design goals. We will determine later in the
document (in Section 5) which requirements are already fulfilled by
MIPv6 and what issues remain in order to meet the requirements not
currently fulfilled by MIPv6.
Basically, Internet connectivity is guaranteed for a MN as long as at
least one path is maintained between the MN and the fixed Internet.
This path can be divided into two paths: the path between the MN to
its HA(s) and the path between the HA(s) and the CN. If RO is in
place between the MN and a CN, an additional path between the MN and
the CN must be guaranted. In some cases, it may be necessary to
divert packets from a (perhaps failed) path to an alternative
(perhaps newly established) path (e.g. for matters of reliability,
preferences), or to split traffic between multiple paths (e.g. for
load sharing, load balancing). The use of an alternative path must
be transparent at layers above layer 3 if broken sessions and the
establishment of new transport sessions has to be avoided.
In order to meet some of the goals (particularly load balancing and
load sharing), multiple paths must be maintained simultaneously
between the mobile node and its CN.
This can translate into the following enumeration of requirements:
1. A MN must have either multiple interfaces with at least a single
valid global IP address on each interface, or a single interface
with more than one valid global address, or a single interface
with one valid global address and multiple HoAs.
Montavont, et al. Expires April 30, 2006 [Page 8]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
2. A MN must be able to use multiple interfaces simultaneously when
it is equipped with multiple interfaces.
3. A MN must be able to attach distinct interfaces to different
access networks (distinct foreign links or distinct home links,
or a combination of both), when it is equipped with multiple
interfaces.
4. A MN should be able to share its traffic load among its
interfaces, when several interfaces are activated and configured
with valid addresses.
5. A mechanism should be available to quickly activate a backup
interface and redirect traffic when an interface fails (e.g.,
loss of connection).
6. A mechanism should be available to quickly redirect flow from one
address to another when it is needed. Some of the triggers of
flow redirection are given in Appendix A.
7. The MN must be able to use multiple HAs simultaneously for a
given home address.
8. The MN must be able to use a distinct HA for each home address
simultaneously.
One has to consider whether these goals can be achieved with
transparency or without transparency. Transparency is achieved when
switching between interfaces does not cause the disruption of on-
going sessions. To be achieved with transparency, a necessary (may
or may not be sufficient) condition is for the end-point addresses to
remain unchanged. This is in-view of the large amount of Internet
traffic today are carried by TCP, which unlike SCTP, cannot handle
multiple end-point address pairs.
In future when a Shim6 protocol is designed and deployed, upper layer
transparency may be maintained even if end-point addresses are
changed. However, as Shim6 is in its early design phase as of the
writing of this memo, we will continue to assume that an end-point
address change would cause a transport layer disruption throughout
this document.
Montavont, et al. Expires April 30, 2006 [Page 9]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
4. Taxonomy
In order to examine the issues preventing a MIPv6 mobile node to meet
the requirements listed in Section 3 we use in the present document
the following taxonomy (x,y) where:
o x = number of Home Addresses (HoAs)
o y = number of Care-of Addresses (CoAs)
A value of '1' implies there is a single instance of the parameter,
whereas a value of 'n' indicates that there are multiple instances of
the parameter. A value '*' indicates that the number can be '1' or
'n'.
An illustration of this taxonomy is given in Figure 1.
Mobile Node
HoA1 HoA2 ... HoAn --> Permanent Address (x)
| | |
+-----+--------+ | |
| | | | |
CoA1 +--CoA2 +---CoA3 ... CoAn --> Temporary Address (y)
| | | |
Link1 Link2 Link3 ... Linkn --> IPv6 Link (n/a *)
| | | |
+-----+----+ | |
| | |
IF1 IF2 ... IFn --> Physical layer
HoA1 ::= {CoA1, 2, 3} [IF1 and IF2]
HoA2 ::= {CoA3} [IF2]
Mobile Node(x = 2, y = 3)
* because number of IPv6 links is equal to the number of CoAs, y
Figure 1: Illustration of the Taxonomy
As the taxonomy suggests, the fact that the mobile node has several
HoAs is independent from the fact that the mobile node has multiple
interfaces. The fact that the mobile node has multiple interfaces
does not imply that it has multiple HoAs and vice-versa. Similarly,
the number of CoAs is independent from the number of HoAs and the
number of interfaces. While a node would probably have at least one
CoA per interface, multiple prefixes available on a link may lead to
the node building several CoAs on that link.
Montavont, et al. Expires April 30, 2006 [Page 10]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
We propose a taxonomy with two parameters because each of them has an
influence on either the mobile node behavior / management, or the
potential benefits the mobile node may obtain from such
configuration.
The configurations denoted by these parameters will have an impact on
the way multihoming is supported. According to the number of HoAs
and CoAs, different policies will be needed, such as which CoA has to
be mapped with which HoA, do all the CoAs need to be mapped with all
the HoAs, etc.
Montavont, et al. Expires April 30, 2006 [Page 11]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
5. Scenarios
In this section, we detail the reachable multihoming goals under each
type of configuration. For each configuration, we give a basic
explanation and we list which of the goals outlined in Section 3 are
achievable provided that supporting mechanisms are either already
existing or could be defined. Other goals are not achievable due to
the inherent configuration of the node. Then, we briefly discuss the
current situation with MIPv6 and we point to issues discussed later
in this document in Section 6.1, Section 6.2 and Section 6.3.
5.1. (1,1): 1 HoA, 1 CoA
When the node has a single network interface, it is not multihomed.
The node has only one interface, with one HoA and is currently away
from its home link. A CoA is configured on the foreign link. This
is the usual scenario considered by Mobile IPv6 which would bind that
CoA to the HoA. None of the multihoming goals are achievable.
However, when the node has several interfaces, this scenario is a
very special case of a node with multiple interfaces connected to
different IPv6 subnets. The MN is multihomed if one of the interface
is attached to a foreign link, the other one is attached to the home
link. Thus, the MN only configures one CoA on the foreign subnet,
and one HoA on the home link.
There cannot be more than two interfaces, otherwise the mobile node
would either have (A) multiple interfaces on the home link, or (B)
multiple interfaces on foreign links. For (A), there would be
multiple HoAs. For (B) there would be multiple CoAs.
Achievable goals: ubiquitous access, reliability, load sharing, load
balancing, preference settings, bicasting
Current situation with MIPv6:
o Ubiquitous Access and reliability
These goals are achievable, but in a limited manner. The MN can
build a temporary IPv6 address on its other interface but it
cannot register the temporary address with its HA because the node
is using its HoA. If the node needs to update its location
following a movement, it will not be able to use its HoA on the
interface connected to its home link. This issue is detailed in
Section 6.2.3.
As MIPv6 cannot be used on these addresses, the MN will not be
able to redirect any flow to another address. For instance, if
Montavont, et al. Expires April 30, 2006 [Page 12]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
the MN looses its connection to its home link, all flows must be
initiated again with the CoA address valid on the other interface
of the MN. Fault recovery is then only possible without
transparency and none of the MIPv6 features can help in case of a
failure.
o Preference Settings, Load Sharing and Load Balancing
The MN is able to use both interfaces at the same time, according
to some preference settings on its side to decide which one to use
for which application. Therefore load sharing and load balancing
can be achieved when communication are initiated by the MN. When
a CN initiates a communication with the MN, it would choose the
destination address depending on the available information about
the MN (e.g., DNS request). Presently there is no mechanism
allowing the MN to indicate on which interface (i.e., address) a
CN may reach it. If only one address is known by distant node,
load sharing and load balancing will not be achieved. See in
Section 6.1.1 where such path selection issues are discussed.
o Bicasting
Bicasting should be possible since the MN has two addresses. The
MN should be able to request any CN to duplicate traffic to both
addresses. However, MIPv6 does not allow the MN to request
bicasting on the CN (see Section 6.2.3).
5.2. (n,1): n HoAs, 1 CoA
The MN is multihomed, since it has several HoAs. This case may
happen when a node is getting access to the Internet through
different HAs (possibly distinct operators) and each offers a Mobile
IPv6 service to the node. That way, the node will have a HoA per HA.
Alternatively, a single home network may be multihomed to the
Internet, leading to having multiple prefixes on the home link. Thus
the MN would have multiple HoAs for a single home link. Either case,
the node would need to configure a single CoA on the visited IPv6
subnet, and bind that single CoA to all the HoAs it owns. If the MN
has multiple interfaces, only one interface is connected to a foreign
network. The other interfaces are connected to their home links.
Achievable goals: Ubiquitous access, reliability, load sharing, load
balancing (if the MN has more than one interface), bicasting,
preference settings.
Current situation with MIPv6:
Montavont, et al. Expires April 30, 2006 [Page 13]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
o Reliability and ubiquitous access
If there is a failure in one of the home networks of the MN (e.g.,
one HA of the MN is disconnected from the network) MIPv6 does not
provide any mechanism to hand-over the communication to another
HoA. If a HoA, which is used at the transport layer by an
application, needs to be changed, the application must be
restarted. MIPv6 does not allow changing of the HoA transparently
for a given transport session. Currently, fault tolerance is not
achieved in this case, since established communications cannot be
preserved. See the corresponding discussion in Section 6.3.3. If
the MN has multiple interfaces and is disconnected from its home
link, MIPv6 allows the MN to redirect flows transparently to a
CoA. If the CoA changes (e.g., failure of the interface, or
movement), MIPv6 allows to transparently redirect flows which were
using this address as temporarily address (i.e., communication is
using a HoA as main address) to another address. If sockets were
directly opened via the CoA, loss of the address will imply to
initiate again the communication. In conclusion, fault recovery
can only be done in some cases, when flows were initiated via a
HoA.
o Preference Settings and Load Sharing
In BT mode, preference settings and load sharing only affect the
path between the CN and the HA(s), and not the path between the MN
and the HA(s), as long as the CoA does not change. In RO mode,
the path between the MN and the CN does not change if the CoA does
not change. As an entry in the binding cache is identified by a
HoA, the MN can register the same CoA with all HoAs, on any
distant node. A mechanism would then be needed for the MN to
select which HoA should be used when a new communication flow is
initiated. A similar mechanism is needed on the CN side if it
knows that multiple HoAs are assigned to the same MN. With such
mechanisms, it would be possible to use multiple HoAs at the same
time, and load sharing could be performed. See in Section 6.1.1
where such path selection issues are discussed. It is also
possible that the MN register one HoA as a CoA for another HoA
(see discussions in Section 6.2.2).
o Bicasting
Bicasting could be achieved in this scenario by registering two
addresses with a single HoA. However MIPv6 does not provide any
mechanism to associate more than one CoA with one HoA. Moreover,
in this particular case, one HoA should be taken as a CoA
regarding the other HoA. (see discussions in Section 6.2.1 and
Section 6.2.2).
Montavont, et al. Expires April 30, 2006 [Page 14]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
5.3. (1,n): 1 HoA, n CoAs
The MN is multihomed since it has several CoAs. This case may occur
when the interface of the node is connected to a link where multiple
IPv6 prefixes are available. One possible reason for this is that
the visited network is multihomed and because of that, multiple
prefixes are available in it, one per provider. Note that the MN may
be connected to its home link with one of its interfaces.
Achievable goals: reliability, load sharing, bicasting, preference
settings.
Current situation with MIPv6:
o Reliabiility
Fault recovery will be limited to the case where one of the CoA
become unreachable for a particular peer. A CoA may become
unreachable because the ISP which provides the IPv6 prefix fails
for example. Fault recovery in MIPv6 is achieved by associating
an alternate CoA to replace the failed one. However, efficient
mechanisms are needed to determine that a CoA has failed (see
Section 6.1.3) and to determine which CoA should be used instead
(see below).
o Preference Setting, Load Sharing, Load balancing and Bicasting
This configuration allows to share the load and set preferences
among different paths between the HA and the MN when BT mode is
used, and between the CN and the MN when RO mode is used. In
order to achieve load sharing under this scenario, the MN would
need to register several CoAs with its unique HoA. However, the
present specification of MIPv6 only allows the MN to register a
single CoA per HoA. This is discussed in Section 6.2.1. When a
single HoA is bounded with several CoAs at the same time, the MN
or HA/CN would need to select which CoA should be used. This
selection could be done based on user/application preferences (see
Section 6.1.1).
5.4. (n,n): n HoAs, n CoAs
The MN is multihomed since it has multiple addresses. This case can
be viewed as a combination of the two cases described above: the MN
has several HoAs (e.g. given by different operators) and several CoAs
(e.g. because the node is receiving multiple IPv6 prefixes). As an
example, we can consider a node with three interfaces, two of them
connected to their home link (two different HoAs) and the last one
connected to a visited link where two IPv6 prefixes are available.
Montavont, et al. Expires April 30, 2006 [Page 15]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
Achievable goals: ubiquitous access, reliability, load sharing, load
balancing, bicasting, preferences settings.
Current situation with MIPv6
o Reliability
If one CoA becomes unreachable (similar to scenario (1,n) in
Section 5.3), the MN can redirect flows to another CoA by
associating any other available CoAs to the corresponding HoA. If
the MN can not use one of its HoA anymore (similar to scenario
(n,1) in Section 5.2), the MN will have to re-initiate all flows
which were using the corresponding HoA. Redirection between the
addresses available for the MN will be different depending on this
HoA / CoA binding policies.
o Preference Settings, Load Sharing and Bicasting
Currently, the MN can register only one CoA per HoA (see
Section 6.2.1), but it can register the same or different CoAs
with multiple HoAs. If the MN chooses to bind the same CoA to all
its HoAs, we fall in the (n,1) case. In this case, load sharing
can only be performed if route optimization is not used, on the
CN-HA path, as a different HoA may be used per CN. If the MN
chooses to bind a different CoA for each HoA, load sharing will be
done along the whole path across the MN and its CNs. Preference
settings may define which CoA (eventually several if bicasting is
used) should be bound to which HoA (see Section 6.1.1).
In a very specific situation, one of the routable address of the
MN (i.e., which can be directly used without tunneling to reach
the MN) can be one of its HoA. In this case, this HoA can be
viewed as a CoA to bind with another HoA. Thus the MN may be able
to register one HoA as CoA regarding another HoA (see
Section 6.2.2). MIPv6 does not prevent this behavior, which allow
to set a certain preference on addresses usage.
5.5. (n,0): n HoAs, no CoAs
This case happens when the interfaces are connected to their
respective home links. This node can be considered as a fixed node
from a multihoming point of view. The node would no longer be in the
(n,0) configuration when one or more of the interfaces are attached
to foreign links.
Achievable goals: ubiquitous access, reliability, load sharing, load
balancing, bicasting, preference settings.
Montavont, et al. Expires April 30, 2006 [Page 16]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
Current situation with MIPv6
o Ubiquitous Access and reliability
If the MN is disconnected from one of its interfaces, the MN
should be able to register another valid HoA to its failed HoA
(see issue Section 6.2.2).
o Preference Settings, Load Sharing, Load Balancing
This can be achieved when the MN is initiating the communication
flow, as it can choose which HoA should be used. Depending on how
CN can discover HoAs of the MN, these goals might also be achieved
when the CN is initiating the communication flow. See previous
scenario and discussions in Section 6.1.1 about the path
selection. If the flows binding on interfaces preferences change
over time, the MN should be able to redirect one flow from one
interface to another. However, MIPv6 only allows to redirect all
flows from one interface to another, assuming one HoA is
registered as CoA (see issue Section 6.2.2). If the MN policies
indicate to redirect only one flow, a supplementary mechanism
would be needed.
o Bicasting
MN should be able to request bicasting from any CN, to duplicate
traffic to several HoAs. To do so, multiple addresses have to be
registered with one HoA (see Section 6.2.1), and HoA(s) should be
used as CoAs for other HoAs (see Section 6.2.2).
Montavont, et al. Expires April 30, 2006 [Page 17]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
6. Issues
Existing protocols may not be able to handle the requirements
expressed in Section 3. For doing so, the issues discussed in this
section must be addressed, and solved preferably by dynamic
mechanisms. Note that some issues are pertaining to MIPv6 solely,
whereas other issues are not at all related to MIPv6. However, such
non MIPv6 issues must be solved in order to meet the requirements
outlined in Section 3.
In this section, we describe some of these issues in two main
headings: general IPv6-related issues, and issues that are specific
to MIPv6. Other concerns related to implementations of MIPv6 are
described in Section 6.3. Issues and their area of application are
summarized in Section 6.4
6.1. General IPv6-related Issues
6.1.1. Path Selection
When there exists multiple paths from and to the MN, the MN ends up
choosing a source and destination address, and possibly the interface
that should be used.
o Interface selection
When the node has multiple available interfaces, the simultaneous
or selective use of several interfaces would allow a mobile node
to spread flows between its different interfaces.
Each interface could be used differently according to some user
and applications policies and preferences that would define which
flow would be mapped to which interface and/or which flow should
not be used over a given interface. How such preferences would be
set on the MN is out of scope of MIPv6 and might be implementation
specific. On the other hand, if the MN wishes to influence how
preferences are set on distant nodes (Correspondent Node or Home
Agent), mechanisms such as those proposed in [5], [6] and [7]
could be used.
o HoA Selection
When multiple HoAs are available, the MN and its communicating
peers (HA and CNs) must be able to select the appropriate HoA to
be used for a particular packet or flow.
This choice would be made at the time of a new communication flow
set up. Usual IPv6 mechanisms for source and destination address
Montavont, et al. Expires April 30, 2006 [Page 18]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
selection, such as "Default Address Selection for IPv6" [8] could
be used.
However, in RFC3484 it is said that "If the eight rules fail to
choose a single address, some unspecified tie-breaker should be
used". Therefore more specific rules in addition to those
described on RFC3484 may be defined for HoA selection.
o CoA Selection
When multiple CoAs are available, the MN and its communicating
peers (HA and CNs) must be able to select the appropriate CoA to
be used for a particular packet or flow. the MN must use its
internal policies to distribute its flow, but also to distribute
policies on distant nodes to allow them to select the right CoA.
Solutions like nomadv6 [7] or HA filtering [6] may be used.
Another related aspect of path selection is the concern of ingress
filtering. This is detailed in Section 6.1.2.
6.1.2. Ingress Filtering
In the (*,n) case, a MN may be connected to multiple access networks
or multiple home networks each practicing ingress filtering [9],
[10]. Thus, to avoid ingress filtering, the selection of path would
be limited by the choice of address used. This is related to
Section 6.1.1. The problem of ingress filtering however, is two-
fold. It can occur at the access network, as well as the home
network.
For instance, consider Figure 2 below. In the access network, when
mobile node MN sends a packet through AR-A, it must use CoA=PA.MN;
and when MN sends a packet through AR-B, it must use CoA=PB.MN. In
the home network, when MN tunnels the packet to home agent HA-1, it
must use HoA=P1.MN; and when MN tunnels the packet to home agent
HA-2, it must use HoA=P2.MN. This greatly limits the way MN can
benefit from its multihoming configuration.
As an illustration, suppose MN is choosing the interface (which would
determine the CoA used) and the home network to use (which would
determine the HoA used), it might be possible that the chosen CoA is
not registered with the chosen HoA.
Montavont, et al. Expires April 30, 2006 [Page 19]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
Prefix: PA +------+ +----------+ +------+
HoA: P1.MN /-----| AR-A |----| |----| HA-1 |
CoA: PA.MN / +------+ | | +------+
+----+ | | Prefix: P1
| MN | | Internet |
+----+ | | Prefix: P2
HoA: P2.MN \ +------+ | | +------+
CoA: PB.MN \-----| AR-B |----| |----| HA-2 |
Prefix: PB +------+ +----------+ +------+
Figure 2: MN connected to Multiple Access/Home Networks
It must be noted that should the mobile node MN have a way of binding
both CoAs PA.MN and PB.MN simultaneously to each of HoAs P1.MN and
P2.MN (see Section 6.2.1), then it can choose the CoA to use based on
the access network it wishes to use for outgoing packets. This
solves the first part of the problem: ingress filtering at the access
network. It is, nonetheless, still limited to using only a specific
home agent for the home-address used (i.e. the second problem of
ingress filtering at the home network remains unsolved).
6.1.3. Failure detection
Currently, IPv6 has no clearly defined mechanism for failure
detection. A failure in the path between two nodes can be located at
many different places: the media of one of the node is broken (i.e.,
loss of connectivity), the path between the MN and the HoA is broken,
the home link is disconnected from the Internet, etc. By now, MIPv6
only relies on the ability or the inability to receive Router
Advertisements within a stipulated period to detect the availibility
or loss of media. Current effort [11] in the DNA Working Group aims
to address this, such as through the use of layer 2 triggers [12].
Movement detection might be extended to include other triggers such
as the loss of connectivity on one interface. Moreover, the chosen
Further mechanisms would be needed to detect a failure in the path
between a MN and its CN(s), as well as between the MN and its HoA(s),
as between the MN and CN(s), as between the MN and CN(s).
6.2. MIPv6-specific Issues
6.2.1. Binding Multiple CoAs to a given HoA
In the (1,n) cases, multiple CoAs would be available to the MN. In
order to use them simultaneously, the MN must be able to bind and
register multiple CoAs for a single HoA with both the HA and the CNs.
The MIPv6 specification is currently lacking such ability.
Although in the (n,n) cases, MIPv6 allows MN to have multiple HoA and
Montavont, et al. Expires April 30, 2006 [Page 20]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
CoA pairs, the upper layer's choice of using a particular HoA would
mean that the MN is forced to use the corresponding CoA. This
constrains the MN from choosing the best (in terms of cost, bandwidth
etc) access link for a particular flow, since CoA is normally bound
to a particular interface. If the MN can register all available CoAs
with each HoA, this would completely decouple the HoA from the
interface, and allow the MN to fully exploit its multihoming
capabilities.
To counter this issue, solutions like [13] may be used.
6.2.2. Using one HoA as a CoA
In (n,*) cases, the MN has multiple HoAs. A HoA may be seen as a CoA
from the perspective of another home link of the same MN.
As an example, a MN has two HoAs (HoA1 and HoA2) on two distinct home
links. MN is connected to these two home links via two interfaces.
If the MN looses its connectivity on its first interface, HoA1 is not
reachable. It may then want to register HoA2 as a CoA for HoA1 in
order to keep receiving packets intended to HoA1, via the second
interface.
According to the definition of a CoA, the current MIPv6 specification
prohibits registering another HoA as a CoA.
In RFC3775 section 6.1.7 it is written: " Similarly, the Binding
Update MUST be silently discarded if the care-of address appears as a
home address in an existing Binding Cache entry, with its current
location creating a circular reference back to the home address
specified in the Binding Update (possibly through additional
entries)."
In other words, the BU must be discarded if the binding cache of the
receiver is:
Binding Cache:
New BU: HoA = addr1 w/ CoA = addr2
existing entries: HoA = addr2 w/ CoA = addr3
HoA = addr3 w/ CoA = addr1
But, in the following situation:
Binding Cache:
New BU: HoA = addr1 w/ CoA = addr2
existing entries: HoA = addr2 w/ CoA = addr3
and no other entries in the binding cache concerning addr1/2/3. In
Montavont, et al. Expires April 30, 2006 [Page 21]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
this case, the BU should be accepted.
In order to counter this, a MN must be able to register whatever
address it owns with any of its HoA. A mechanism is needed to
determine how to decide which HoA will be chosen and the definition
of a HoA and CoA might be extended. Some addtional details can be
found in [14].
6.2.3. Simultaneous location in home and foreign networks
Rule 4 of RFC3484 specifies that a HoA will always be preferred to a
CoA. While this rule allows to choose which address to use, it does
not allow to beneft from being multihomed. When a MN is multihomed,
it may have one of its interfaces directly connected to a home link.
This may have an impact on the way multihoming is managed, since
addresses from other interfaces cannot be registered as CoAs for the
HoA associated to the home link the mobile node is connected on.
In the special case of (1,*) where one of the interface is connected
to the home link, none of the other addresses can be used to achieve
multihoming goals with the HA.
6.3. Considerations for MIPv6 Implementation
In addition to the issues described in Section 6.1 and Section 6.2,
there are other concerns implementers should take into consideration
so that their MIPv6 implementations are more "friendly" to the use of
multiple interfaces. These implementation-related considerations are
described in the sub-sections below.
6.3.1. Binding a new CoA to the right HoA
In the (n,*) cases, the MN has multiple HoAs. When the MN moves and
configures a new CoA, the newly obtained CoA must be bound to a
specific HoA. The current MIPv6 specification doesn't provide a
decision mechanism to determine to which HoA this newly acquired CoA
should be bound to.
With no such mechanism, the MN may be confused and may bind this CoA
to a possibly wrong HoA. The result might be to bind the CoA to the
same HoA the previous CoA was bound to or to another one, depending
on the implementation. It would indeed be better to specify the
behavior so that all implementations are compliant.
6.3.2. Binding HoA to interface
In (n,*) cases, MIPv6 does not provide any information on how HoAs
should be bound on a device, and particularly there is no mechanism
Montavont, et al. Expires April 30, 2006 [Page 22]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
to bind HoAs to interfaces.
This may be troublesome, for example, when we consider a MN
configured with two HoAs and equipped with three interfaces. When
the MN is connected to a home link via one interface, it will need to
bind the corresponding HoA to this interface, even if the HoA was
initially assigned to another one.
HoA1 HoA2
CoA1 CoA2 CoA3
Iface1 Iface2 Iface3
Figure 3: Illustration of the case (2,3)
HoA must always be assigned to an activated interface and if the MN
is connected to its home link, the corresponding HoA must be used on
this interface. In some cases, the HoA then would have to be re-
assigned to another interface in case of connection loss or
attachment to the home link.
6.3.3. Flow redirection
Internet connectivity is guaranteed for a MN as long as at least one
path is maintained between the MN and its CN. When an alternative
path must be found to substitute for another one, the loss of one
path to the Internet may result in broken sessions. In this case,
new transport sessions would have to be established over the
alternate path if no mechanism is provided to redirect flow
transparently at layers above layer 3. The need for flow redirection
is given in Appendix A.
The different mechanisms that can be used to provide flow redirection
can be split into two categories, depending on the part of the path
that needs to be changed. The first category is when the CoA
changes: if one of the MN's CoA needs to be changed, it influences
the path between the MN and its HA, and the path between the MN and
its CN in RO mode. If the MN has multiple interfaces and one fails,
established sessions on the failed interface would break if no
support mechanism is used to redirect flows from the failed interface
to another.
The second category is when the HoA changes: if one of the MN's HoA
needs to be changed, it influences the path between the CN and the
HoA. In (n,*) cases, the MN has multiple HoAs. If one fails,
established sessions on the failed HoA would break if no support
mechanism is used to redirect flows from a failed HoA to another,
unless the transport session has multihoming capabilities, such as
Montavont, et al. Expires April 30, 2006 [Page 23]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
SCTP, to allow dynamic changing of addresses used.
6.4. Summary
+=================================================+
| # of HoAs: | 1 | 1 | n | n |
| # of CoAs: | 1 | n | 1 | n |
+=================================================+
| General IPv6 Issues |
+---------------------------------+---+---+---+---+
| Path Selection | | o | o | o |
+---------------------------------+---+---+---+---+
| Ingress Filtering | | | o | o |
+---------------------------------+---+---+---+---+
| Failure detection |o | o | o | o |
+---------------------------------+---+---+---+---+
| MIPv6-Specific Issues |
+---------------------------------+---+---+---+---+
| Binding Multiple CoAs to a | | o | o | o |
| given HoA | | | | |
+---------------------------------+---+---+---+---+
| Using one HoA as a CoA | | | o | o |
+---------------------------------+---+---+---+---+
| Simultaneous location in home | | o | o | o |
| and foreign networks | | | | |
+---------------------------------+---+---+---+---+
| Implementation-Related Concerns |
+---------------------------------+---+---+---+---+
| Binding a new CoA to the | | | o | o |
| right HoA | | | | |
+---------------------------------+---+---+---+---+
| Binding HoA to interface(s) | o | o | o | o |
+---------------------------------+---+---+---+---+
| Flow redirection | o | o | o | o |
+=================================================+
Figure 4: Summary of Issues and Categorization
Montavont, et al. Expires April 30, 2006 [Page 24]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
7. TODO List
Study security concerns
Possibly discuss the possibility to use HoA on both home link and
foreign link as in case (1,1):
Mention about relation with Multi6 / Shim6.
Montavont, et al. Expires April 30, 2006 [Page 25]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
8. Conclusion
In this document, we have raised issues related to multihoming. We
have seen that mechanisms are needed to redirect flow from a failed
path to a new path, and mechanisms to decide which path should better
be taken when multiple paths are available. This raises a number of
issues.
Even if MIPv6 can be used as a mechanism to manage multihomed MN,
triggers of flows redirection between interfaces/addresses are not
adapted to the multihoming status of the node. Also, we have shown
that in some scenarios MIPv6 is ambiguous in the definitions of CoA/
HoA and in the mappings between HoAs, CoAs and network interfaces.
Finally, we have also raised issues not directly related to MIPv6,
but solutions for these issues are needed for mobile nodes to fully
enjoy the benefits of being multihomed.
Montavont, et al. Expires April 30, 2006 [Page 26]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
9. Contributors
The following people have contributed ideas, text and comments to
this draft: Eun Kyoung Paik from Seoul National University, South
Korea and Thomas Noel from Universite Louis Pasteur, Strasbourg,
France.
Montavont, et al. Expires April 30, 2006 [Page 27]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
10. Acknowledgments
The authors would like to thank all the people who have sent comments
so far, particularly Tobias Kufner for raising new issues.
11. References
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
[3] Ernst, T., Montavont, N., Wakikawa, R., Paik, E., Ng, C.,
Kuladinithi, K., and T. Noel, "Goals and Benefits of
Multihoming", draft-multihoming-generic-goals-and-benefits-02
(work in progress), October 2005.
[4] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[5] Soliman, H., Malki, K., and C. Castelluccia, "Per-flow movement
in MIPv6", draft-soliman-mobileip-flow-move-02 (work in
progress), July 2002.
[6] Montavont, N. and T. Noel, "Home Agent Filtering for Mobile
IPv6", draft-montavont-mobileip-ha-filtering-v6-00 (work in
progress), January 2004.
[7] Kuladinithi, K., "Filters for Mobile IPv6 Bindings (NOMADv6)",
draft-nomadv6-mobileip-filters-02 (work in progress),
June 2004.
[8] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[9] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[10] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[11] Choi, J., "Goals of Detecting Network Attachment in IPv6",
draft-ietf-dna-goals-04 (work in progress), December 2004.
Montavont, et al. Expires April 30, 2006 [Page 28]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
[12] Yegin, A., "Link-layer Event Notifications for Detecting
Network Attachments", draft-ietf-dna-link-information-02 (work
in progress), July 2005.
[13] Wakikawa, R., "Multiple Care-of Addresses Registration",
draft-wakikawa-mobileip-multiplecoa-04 (work in progress),
June 2005.
[14] Montavont, N., "Mobile IPv6 for multiple interfaces (MMI)",
draft-montavont-mip6-mmi-02 (work in progress), July 2005.
[15] Yegin, A., "Link-layer Hints for Detecting Network
Attachments", draft-yegin-dna-l2-hints-01 (work in progress),
February 2004.
Montavont, et al. Expires April 30, 2006 [Page 29]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
Appendix A. Why a MN may want to redirect flows
When a MN is multihomed, an addresses selection mechanism is needed
to distribute flows over interfaces. As policies may change over
time, as well as the available addresses/interfaces, flow redirection
mechanisms are needed. While the selection policy is out of scope of
this document, the following reasons may trigger the MN to redirect
flow from one address to another:
o Failure detection: the path between the MN and its CN(s) is
broken. The failure can occur at different places onto this path;
The failure can be local on the MN, where the interface used on
the MN is disconnected from the network (e.g., a wireless
interface which comes out of range from its point of attachment).
Alternatively, the failure can be on the path between the MN and
one of its HA. Yet another alternative is that the failure can be
on the path between the HA and the CN. If route optimization is
used, it can also be a failure between the MN and its CN(s).
o New address: a new address on the MN comes available. This can be
the case when the MN connects to the network with a new interface.
The MN may decide that this new interface is most suitable for its
current flows that are using another interface.
o Uninterrupted horizontal handover in mobility: If the MN is
mobile, it may have to change its point of attachment. 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 the flows exchanged on the interface can be interrupted. 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 prior to the handover if L2 triggering is considered
[12] [15]
o Change in the network capabilities: 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 Initiation of a new flow: 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 April 30, 2006 [Page 30]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
Authors' Addresses
Nicolas Montavont
Ecole Nationale Superieure des telecommunications de Bretagne
2, rue de la chataigneraie
Cesson Sevigne 35576
France
Phone: (+33) 2 99 12 70 23
Email: nicolas.montavont@enst-bretagne.fr
URI: http://www-r2.u-strasbg.fr/~montavont/
Ryuji Wakikawa
Keio University
Department of Environmental Information, Keio University.
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan
Phone: +81-466-49-1100
Fax: +81-466-49-1395
Email: ryuji@sfc.wide.ad.jp
URI: http://www.wakikawa.net/
Thierry Ernst
Keio University / WIDE
Jun Murai Lab., Keio University.
K-square Town Campus, 1488-8 Ogura, Saiwa-Ku
Kawasaki, Kanagawa 212-0054
Japan
Phone: +81-44-580-1600
Fax: +81-44-580-1437
Email: ernst@sfc.wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~ernst/
Montavont, et al. Expires April 30, 2006 [Page 31]
Internet-Draft Analysis of Multihoming in MIPv6 October 2005
Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
SG
Phone: +65 65505420
Email: chanwah.ng@sg.panasonic.com
Koojana Kuladinithi
University of Bremen
ComNets-ikom,University of Bremen.
Otto-Hahn-Allee NW 1
Bremen, Bremen 28359
Germany
Phone: +49-421-218-8264
Fax: +49-421-218-3601
Email: koo@comnets.uni-bremen.de
URI: http://www.comnets.uni-bremen.de/~koo/
Montavont, et al. Expires April 30, 2006 [Page 32]
Internet-Draft Analysis of Multihoming in MIPv6 October 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 April 30, 2006 [Page 33]