MEXT Working Group N. Montavont
Internet-Draft IT/Telecom Bretagne
Intended status: Informational R. Wakikawa
Expires: November 4, 2008 Toyota ITC/Keio Univ.
T. Ernst
INRIA
C. Ng
Panasonic Singapore Labs
K. Kuladinithi
University of Bremen
May 3, 2008
Analysis of Multihoming in Mobile IPv6
draft-ietf-monami6-mipv6-analysis-05
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 November 4, 2008.
Abstract
Mobile IPv6 as specified in RFC 3775 allows a mobile node to maintain
its IPv6 communications while moving between subnets. This document
investigates configurations where a mobile node running Mobile IPv6
is multihomed. The use of multiple addresses is foreseen to provide
ubiquitous, permanent and fault-tolerant access to the Internet,
Montavont, et al. Expires November 4, 2008 [Page 1]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
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. The purpose of this document is
to detail all the issues arising through the operation of Mobile IPv6
on multihomed mobile nodes.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Goals and Node Capabilities . . . . . . . . . . . . . . . . . 6
4. Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Analysis of Multihoming Configurations . . . . . . . . . . . . 9
5.1. (1,1): 1 HoA, 1 CoA . . . . . . . . . . . . . . . . . . . 9
5.2. (n,1): n HoAs, 1 CoA . . . . . . . . . . . . . . . . . . . 11
5.3. (1,n): 1 HoA, n CoAs . . . . . . . . . . . . . . . . . . . 13
5.4. (n,n): n HoAs, n CoAs . . . . . . . . . . . . . . . . . . 14
5.5. (n,0): n HoAs, no CoAs . . . . . . . . . . . . . . . . . . 16
6. Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 16
6.1. General IPv6-related Issues . . . . . . . . . . . . . . . 16
6.1.1. Failure Detection . . . . . . . . . . . . . . . . . . 16
6.1.2. Path Exploration . . . . . . . . . . . . . . . . . . . 17
6.1.3. Path Selection . . . . . . . . . . . . . . . . . . . . 18
6.1.4. Rehoming . . . . . . . . . . . . . . . . . . . . . . . 19
6.1.5. Ingress Filtering . . . . . . . . . . . . . . . . . . 20
6.2. MIPv6-specific Issues . . . . . . . . . . . . . . . . . . 21
6.2.1. Binding Multiple CoAs to a given HoA . . . . . . . . . 21
6.2.2. Simultaneous Location in Home and Foreign Networks . . 21
6.2.3. HA Synchronization . . . . . . . . . . . . . . . . . . 22
6.3. Considerations for MIPv6 Implementation . . . . . . . . . 22
6.3.1. Using one HoA as a CoA . . . . . . . . . . . . . . . . 22
6.3.2. Binding a new CoA to the Right HoA . . . . . . . . . . 23
6.3.3. Binding HoA to interface . . . . . . . . . . . . . . . 23
6.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 24
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Why a MN may want to redirect flows . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 31
Montavont, et al. Expires November 4, 2008 [Page 2]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
1. Introduction
With the emergence of performant wireless technologies, nodes are
highly mobile and can change their point of attachment to the
Internet at any time, even during active network connections. To
support such mobility in IPv6, Mobile IPv6 (RFC 3775 [1] and RFC 3776
[2]) allows mobile nodes to maintain ongoing sessions while changing
their points of attachment to the Internet.
Additionally, as explained in [3], ubiquitous, permanent, fault-
tolerant and heterogeneous access to the Internet is required. For
doing so, mobile nodes which are prone to failure or sudden lack of
connectivity may be equipped with multiple interfaces. They may also
be connected to multihomed networks. In such a situation, mobile
nodes would be allocated multiple addresses and are said to be
multihomed. These addresses would be assigned to a single interface
or to multiple interfaces. However, the current specification of
Mobile IPv6 lacks support for using multiple addresses
simultaneously.
Individual solutions have been proposed to extend Mobile IPv6 in such
a way but all issues have not been addressed and not even discussed
in some document.
This study aims at fulfilling this gap and has two goals. The first
goal is to determine the capabilities required for providing
ubiquitous, permanent, fault-tolerant and heterogeneous access to the
Internet to multihomed mobile nodes operating Mobile IPv6. The
second goal is to define the issues arising when we attempt to
fulfill these requirements. The definition of solutions addressing
these issues is out of scope of this document.
To understand the foundation of this study, readers should
familiarize themselves with the 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
for the present study. The reader should also has basic
understanding of the operation of the Mobile IPv6 protocol specified
in RFC3775 [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 recall and refine the design goals behind multihoming
and we discuss what are the required capabilities on the mobile nodes
to fully meet these design goals. Then we propose in Section 4 a
taxonomy to classify the different cases where mobile nodes are
multihomed. Thereafter the taxonomy is used in Section 5 to describe
Montavont, et al. Expires November 4, 2008 [Page 3]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
a number of multihomed configurations specific to Mobile IPv6. For
each case, we show the resulting addressing configuration (number of
Home Addresses, and the number of Care-of Addresses). Each
configuration is illustrated with example diagrams and the means to
meet the requirements are outlined. Finally we discuss in Section 6
all issues related to a multihomed mobile node and we identify what
is missing in order to reach the goals outlined in [3]. These issues
are classified into IPv6 issues, Mobile IPv6-specific issues, and
advices to implementers.
2. Terminology
The terms used in the present document are defined in RFC3753 [4],
RFC3775 [1] and [3].
In this document we are using the following terms and abbreviations:
o MIPv6
The Mobile IPv6 protocol specified in RFC3775 [1]
o Mobile Node (MN)
a Mobile Node operating Mobile IPv6
o HA
a Mobile IPv6 Home Agent
o HoA
a Mobile IPv6 Home Address
o CoA
a Mobile IPv6 Care-of Address
o Multihomed Mobile Node
In the companion document [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 Mobile IPv6, this may
translate into the following definition:
A mobile node is said multihomed when it has either i) multiple
Montavont, et al. Expires November 4, 2008 [Page 4]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
addresses which are used as source addresses or ii) multiple
tunnels to transmit packets, or both.
A mobile node may have multiple tunnels in the following cases:
* When it has multiple home addresses, that is if multiple
prefixes are available on the home link or if it has multiple
interfaces named on (presumably) distinct home links.
* When it has multiple care-of addresses, that is if multiple
prefixes are available on the foreign link or if it has
multiple interfaces attached to (presumably) distinct foreign
links.
* When the home agent has multiple addresses.
o A valid address
An address that is topologically correct (it is configured from
the prefix available on the link the interface is attached to) and
routable.
o Simultaneously using multiple addresses
A mobile node is using multiple addresses simultaneously when an
incoming packet with the destination address set to any of these
addresses reaches the mobile node, or when any of these addresses
can be used by the mobile node as the source address of outcoming
packets.
o Simultaneously using multiple interfaces
A mobile node is using multiple interfaces simultaneously when it
can transmit IP packets over any of these interfaces.
o Bidirectional Tunnel (BT) Mode
Mobile IPv6 Bidirectional tunnel between the mobile node and its
home agent.
o Route Optimization (RO) Mode
Mobile IPv6 Route optimization between the mobile node and its
correspondent node.
Montavont, et al. Expires November 4, 2008 [Page 5]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
3. Goals and Node Capabilities
In this section, we determine what are the capabilities required on
the mobile nodes in order to benefit from multihoming configurations,
as indicated in [3] where a number of goals/benefits are listed:
ubiquitous access, flow redirection, reliability, load sharing,
interface switching, preference settings, and aggregate bandwidth.
These do somewhat overlap, i.e., they are not totally independent.
Reaching one of them may imply reaching another one as well. For
this reason, the following non-overlapping goals could be extracted:
1. Reliability
2. Load Sharing
3. Flow Distribution
From now on, this document will focus on these three non-overlapping
goals, as in this section to determine capabilities. We will
determine later in Section 5 which capabilities are already fulfilled
by Mobile IPv6 and what issues still remain.
Basically, Internet connectivity is guaranteed for a mobile node as
long as at least one path is maintained between the mobile node and
the fixed Internet. This path can be divided into two portions: the
path between the mobile node and its home agent(s) and the path
between the home agent(s) and the correspondent node. If route
optimization is in place between the mobile node and the
correspondent node, an additional path between the mobile node and
the correspondent node must be guaranteed. In essence, the benefit
of multihoming is to allow all or parts of these paths to have
multiple alternatives, so as to achieve reliability, load sharing
and/or flow distribution. 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, flow distribution). 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 flow distribution
and load sharing), multiple paths must be maintained simultaneously
between the mobile node and its correspondent node.
This translates into the following capabilities:
1. A mechanism should be available to quickly activate a backup
interface and redirect traffic when an interface fails (e.g.,
Montavont, et al. Expires November 4, 2008 [Page 6]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
loss of connection).
2. A mechanism should be available to quickly redirect flows from
one address to another when it is needed. Some of the triggers
of flow redirection are given in Appendix A.
3. A mobile node allocated with multiple valid addresses must be
able to use them simultaneously.
4. A mobile node equipped with multiple interfaces (attached to
distinct foreign links or distinct home links, or a combination
of both) must be able to use them simultaneously.
5. A mobile node should be able to distribute its traffic load among
its valid global addresses.
6. If multiple home agents are available to manage bindings for a
given home address, the mobile node should be able to use them
simultaneously or to switch between them.
One has to consider whether these goals can be achieved with
transparency or without transparency. Transparency is achieved when
switching between interfaces/addresses does not cause the disruption
of ongoing sessions. To achieve transparency, a necessary (may or
may not be sufficient) condition is for the end-point addresses at
the transport/application layer to remain unchanged. This is in view
of the large amount of Internet traffic currently carried by TCP,
which unlike SCTP, cannot handle multiple end-point address pairs.
Each of the aforementioned goals can be achieved independently. We
define here which of the above capabilities are needed for each goal:
1. Reliability: 1, 2, 3, 6
2. Load Sharing: 3, 6
3. Flow Distribution: 2, 3, 4, 5, 6
Montavont, et al. Expires November 4, 2008 [Page 7]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
4. Taxonomy
In order to examine the issues preventing a 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 of '0' implies that there is no instance of
this parameter. A value '*' indicates that the number can be '0',
'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
CoA1, CoA2, CoA3 are bound to HoA1 on IF1 and IF2
CoA3 is bound to HoA2 on IF2
* n/a because the number of IPv6 links is equal to number of CoAs (y)
Figure 1: Illustration of the Taxonomy
As the taxonomy suggests, the fact that a mobile node has several
home addresses is independent from it having multiple interfaces.
Having multiple interfaces does not imply that it has multiple home
addresses and vice-versa. Similarly, the number of care-of addresses
is independent from the number of home addresses and the number of
interfaces. While a node would probably have at least one care-of
address per interface, multiple prefixes available on a link may lead
the node to configure several care-of addresses on that link.
Montavont, et al. Expires November 4, 2008 [Page 8]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
The proposed taxonomy has 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 a
configuration.
The configurations denoted by these parameters will have an impact on
how multihoming is supported. Depending on the number of home and
care-of addresses, different policies will be needed, such as "which
care-of address has to be mapped to which home address", "all the
care-of addresses must be mapped with all the home addresses", etc.
The readers should note that for Mobile IPv6, home address is used to
identify a binding. Thus when a mobile node has multiple home
addresses, it would imply the mobile node is using multiple Mobile
IPv6 sessions, regardless of whether all the home addresses are
handled by a single home agent.
5. Analysis of Multihoming Configurations
In this section, we detail all the possible multihoming
configurations. We briefly discuss the current situation with Mobile
IPv6 and we point to issues that will be further detailed in
Section 6.1, Section 6.2 and Section 6.3.
As it is demonstrated below, we notice that:
o When the mobile nodes is equipped with multiple interfaces,
reliability, load sharing and flow distribution can be achieved in
all (*,*) cases.
o When a single interface is available, none of the goals can be
achieved in the (1,1) case (the mobile node is not multihomed).
In all the other cases, only reliability and load sharing can be
achieved.
5.1. (1,1): 1 HoA, 1 CoA
A mobile node in this configuration with only a single network
interface is not multihomed. This configuration is the common case
of a mobile node is away from its home link: the node has one home
address and one care-of address which is configured on the foreign
link. None of the multihoming goals are achievable.
A mobile node in the same configuration but with several interfaces
is multihomed and lead to a special situation where the mobile node
is connected to both its home link and a foreign link. In order to
use both interfaces simultaneously, the home address would be
Montavont, et al. Expires November 4, 2008 [Page 9]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
directly used on the interface connected to the home link, and a
care-of address configured on the other interface connected to a
foreign link. There cannot be more than two active interfaces in the
(1,1) case, 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 home addresses. For (B)
there would be multiple care-of addresses. These are indeed cases
(n,*) (see Section 5.2 , Section 5.4 and Section 5.5) and (*,n) (see
Section 5.3 and Section 5.4), respectively.
We next analyze if Mobile IPv6 can be used to achieve the following
multihoming benefits:
o Reliability
What Mobile IPv6 can achieve
Reliability is achievable, but in a limited manner. Although
the mobile node cannot register its care-of address at its home
agent and use its home link at the same time, it could register
the care-of address with selected correspondent nodes (i.e.
route optimization). In this case, the mobile node can enjoy a
better reliability for communications sessions opened with
these corrrespondent nodes. When the care-of address fails,
the mobile node can either bind a new care-of address with its
home address at the correspondent nodes, or remove the binding
and directly get the packets via the home link.
What is missing for Mobile IPv6
The mobile node cannot register the care-of address configured
on the foreign network with its home address and receive
packets from the home agent via a tunnel to the care-of address
at the same time it receives packet on the home address from
the home link. In addition, if the mobile node looses its
connection on the foreign link, flows that are started by using
the care-of address as a source address must be re-initiated
with another address (either the home address, or a new care-of
address obtained on another foreign link). Fault recovery is
thus only possible without transparency, and Mobile IPv6
features can only recover the failure of the home address.
This issue is detailed in Section 6.2.2.
Reliability could also be achieved through bi-casting since the
mobile node has two addresses and should be able to request any
correspondent node to duplicate traffic to both of them.
However, Mobile IPv6 does not allow the mobile node to request
bi-casting on the correspondent node (see Section 6.2.2).
Montavont, et al. Expires November 4, 2008 [Page 10]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
o Load Sharing, Flow Distribution
What Mobile IPv6 can achieve
The mobile node 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 flow distribution can be achieved when sessions are
initiated by the mobile node. When a correspondent node
initiates a session with the mobile node, it would choose the
destination address depending on the available information
about the mobile node (e.g., DNS request). Presently there is
no mechanism allowing the mobile node to indicate on which
interface (i.e., address) a correspondent node may reach it.
If only one address is known by the distant node, load sharing
and flow distribution cannot be achieved. See in Section 6.1.3
where such path selection issues are discussed.
What is missing for Mobile IPv6
Although the mobile node is able to use both interfaces at the
same time, there is no mechanism that allows the mobile node to
indicate to which interface (i.e., address) a correspondent
node send packets for a particular flow. Section 6.1.3
discusses such path selection issues.
5.2. (n,1): n HoAs, 1 CoA
A mobile node in this configuration is multihomed since it has
several home addresses. This case may happen when a node gets access
to the Internet through different home agents (possibly distinct
operators), each offering a Mobile IPv6 service to the node. That
way, the mobile node would have a home address per home agent.
Alternatively, a single home network may be multihomed to the
Internet, leading to the advertisement of multiple prefixes on the
home link. The mobile node would thus have multiple home addresses
on a single home link.
In either cases, the node would configure a single care-of address on
the visited IPv6 subnet, and bind that single care-of address to all
its home addresses. If the mobile node has multiple interfaces, only
one interface is connected to a foreign network. The other
interfaces are connected to their home links, or are inactive.
We next analyze if Mobile IPv6 can be used to achieve the following
multihoming benefits:
Montavont, et al. Expires November 4, 2008 [Page 11]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
o Reliability
What Mobile IPv6 can achieve
The care-of address may change when the mobile node has
multiple interfaces and is disconnected from its home link
(e.g. failure of the interface, or movement). In such a
situation, Mobile IPv6 allows transparent redirection of flows
using the old care-of address (i.e. the session was initiated
using the home address) to another care-of address. For
sessions directly opened via the care-of address, the loss of
the address implies a re-initiation of the session.
What is missing for Mobile IPv6
If the home agent fails, the session using the failed home
agent must be restarted since Mobile IPv6 does not provide any
mechanism to hand-over transparently from a home agent to
another one. Fault tolerance cannot be achieved in this case,
since established communications cannot be preserved (unless
mechanism such as [6] is used). See the corresponding
discussion in Section 6.1.4 and Section 6.2.3.
If one of the home addresses of the mobile node fails, it means
either that the corresponding home agent has failed (which is
the case discussed above), or the home address is no longer
routed to the home agent. In that latter case, sessions using
that HoA would be terminated, since the home address cannot be
changed transparently.
Reliability through bi-casting could also be achieved by
registering two addresses with a single home address. However
Mobile IPv6 does not provide any mechanism to associate more
than one care-of address with one home address. Moreover, in
this particular case, one home address should be used as a
care-of address bound to the other home address. (see in
Section 6.2.1 and Section 6.3.1).
o Load Sharing
What Mobile IPv6 can achieve
In bidirectional tunnel mode, load sharing only affects the
path between the correspondent node and the home agent(s), and
not the path between the mobile node and the home agent(s), as
long as the care-of address does not change. In route
optimization mode, the path between the mobile node and the
correspondent node does not change if the care-of address does
Montavont, et al. Expires November 4, 2008 [Page 12]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
not change. As an entry in the binding cache is identified by
a home address, the mobile node can register the same care-of
address with all home address, on any distant node.
What is missing for Mobile IPv6
A mechanism would be needed for the mobile node to select which
home address should be used when a new communication flow is
initiated. A similar mechanism is needed on the correspondent
node side if it knows that multiple home addresses are assigned
to the same mobile node. With such mechanisms, it would be
possible to use multiple home addresses at the same time, and
load sharing could be performed. However, it can be noted that
load sharing on the path between the correspondent node and the
home agent might not be the most bandwidth contraint part of
the overall path from the correspondent node to the mobile
node. Thus load sharing might not bring important benefits.
See in Section 6.1.3 where such path selection issues are
discussed. It is also possible that the mobile node register
one home address as a care-of address for another home address
(see in Section 6.3.1).
o Flow Distribution
What Mobile IPv6 can achieve
Flow distribution is achievable when the mobile node is
attached to one foreign link via one of its interfaces and to
the home link(s) via its other interface(s). In this case, the
mobile node can spread flows over its interfaces. Note that if
a correspondent node initiates a communication, the interface
that it will use on the mobile node would depend on which
mobile node's address is advertised to the correspondent node.
5.3. (1,n): 1 HoA, n CoAs
A mobile node in this configuration is multihomed since it has
several care-of addresses. This may occur when the mobile node has
multiple interfaces connected to different links, or when the only
interface is connected to a link where multiple IPv6 prefixes are
advertised (i.e. the visited network is multihomed). Note that one
of the interfaces of the mobile node may be connected to its home
link.
We next analyze if Mobile IPv6 can be used to achieve the following
multihoming benefits:
Montavont, et al. Expires November 4, 2008 [Page 13]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
o Reliability
What Mobile IPv6 can achieve
Reliability support is limited to recover from a failed care-of
address. Fault recovery is achieved in Mobile IPv6 by
associating an alternate care-of address to replace the failed
one.
What is missing for Mobile IPv6
Efficient mechanisms are needed to determine that a care-of
address has failed (see Section 6.1.1), to check reachability
(Section 6.1.2), to determine which care-of address should be
used instead (Section 6.1.3) and to redirect flows to the new
care-of address (Section 6.1.4).
o Load Sharing and Flow Distribution
What Mobile IPv6 can achieve
This configuration allows sharing of the load and setting of
preferences among different paths between the home agent and
the mobile node when bidirectional tunnel mode is used, and
between the correspondent node and the mobile node when route
optimized mode is used.
What is missing for Mobile IPv6
In order to achieve load sharing and flow distribution under
this scenario, the mobile node would need to register several
care-of addresses with its unique home addresses. However, the
present specification of Mobile IPv6 only allows the mobile
node to register a single care-of address per home address.
This is discussed in Section 6.2.1. When a single home address
is bounded to several care-of addresses at the same time, the
mobile node, home agent, or correspondent node must be able to
select the appropriate care-of address. This selection could
be done based on user/application preferences (see
Section 6.1.3).
5.4. (n,n): n HoAs, n CoAs
A mobile node in this configuration is multihomed since it has
multiple addresses. This case can be viewed as a combination of the
two cases described above: the mobile node has several home
addresses, e.g. given by different operators (similar to case (n,1)
in Section 5.2) and several care-of addresses, e.g. because the node
Montavont, et al. Expires November 4, 2008 [Page 14]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
is receiving multiple IPv6 prefixes (similar to case (1,n) in
Section 5.3).
We next analyze if Mobile IPv6 can be used to achieve the following
multihoming benefits:
o Reliability
What Mobile IPv6 can achieve
If one care-of address becomes unreachable (similar to (1,n)),
the mobile node can redirect flows to another care-of address
by binding any of the other available care-of address to the
corresponding home address. If the mobile node can not use one
of its home addresses anymore (similar to (n,1)), the mobile
node will have to re-initiate all flows which were using the
corresponding home address. Redirection between the addresses
available for the mobile node will be different depending on
the binding policies.
What is missing for Mobile IPv6
None specific to (n,n) configuration.
o Load Sharing and Flow Distribution
What Mobile IPv6 can achieve
Although Mobile IPv6 allows the mobile node to register only
one care-of address per home address (see Section 6.2.1), it
can register the same or different care-of addresses with
multiple home addresses. If the mobile node chooses to bind
the same care-of address to all its home addresses, 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 home address may be used per correspondent node.
If the mobile node chooses to bind a different care-of address
for each home address, load sharing will be done along the
whole path across the mobile node and its correspondent nodes.
Preference settings may define which care-of address should be
bound to which home address (see Section 6.1.3).
In a very specific situation, one of the routable address of
the mobile node (i.e., which can be directly used without
tunneling to reach the mobile node) can be one of its home
addresses. This home address would then be viewed as a care-of
address bound to another home address (similar to (n,1)).
Mobile IPv6 does not prevent this behavior, which allows to set
Montavont, et al. Expires November 4, 2008 [Page 15]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
a certain preference on addresses usage. See Section 6.3.1 for
the corresponding issue.
What is missing for Mobile IPv6
None specific to (n,n) configuration.
5.5. (n,0): n HoAs, no CoAs
This case happens when all the interfaces are connected to their
respective home links. This situation is quite similar to a
multihomed fixed node. The node would no longer be in the (n,0)
configuration when one or more of the interfaces are attached to
foreign links.
The mobile node may wish to use one or more home addresses to serve
as the care-of address of another home address (see Section 6.3.1).
In such situations, this scenario is reduced to a (1,1) or (1,n)
configuration as described in Section 5.1 and Section 5.3,
respectively. Analysis of which are already done in those section
and is thus omitted.
6. Multihoming Issues
Existing protocols may not allow reaching the goals 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 Mobile IPv6 solely, whereas other
issues are not at all related to Mobile IPv6. However, such non
MIPv6 issues must be solved in order to meet the goals outlined in
Section 3.
In this section, we describe some of these issues in two main
headings: general IPv6-related issues (Section 6.1), and issues that
are specific to Mobile IPv6 (Section 6.2). Other concerns related to
implementations of Mobile IPv6 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. Failure Detection
It is expected for faults to occur more readily at the edge of the
network (i.e. the mobile nodes), due to the use of wireless
connections. Efficient fault detection mechanisms are necessary to
recover in timely fashion. A failure in the path between two nodes
can be located at many different places: the media of one of the node
Montavont, et al. Expires November 4, 2008 [Page 16]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
is broken (i.e., loss of connectivity), the path between the mobile
node and the home agent is broken, the home link is disconnected from
the Internet, etc. The failure protection domain greatly varies. In
some configurations, the protection domain is limited to a portion of
the path.
So far, Mobile IPv6 only relies on the ability or the inability to
receive Router Advertisements within a stipulated period to detect
the availability or loss of media (local failure).
[7] is addressing such concerns through the use of layer 2 triggers
[8]. Movement detection might be extended to include other triggers
such as the loss of connectivity on one interface. Additional
mechanisms would be needed to detect a failure in the path between a
mobile node and its correspondent node(s), as well as between the
mobile node and its home agent(s), and between the home agent and
correspondent node(s).
6.1.2. Path Exploration
When the mobile node needs to re-home a communication to an
alternative path, a path exploration may take place. The path
exploration is a step that occurs after the failure detection, and
before the path selection. It consists of identifying a set of paths
that are known to provide bidirectional connectivity between the
mobile node and its home agent, and optionally between the mobile
node and its correspondent node. It may be noted that the step of
path exploration may be avoided by selecting a new path, and trying
to re-home the communications on this new path. If the re- homing
fails, a new path is selected until there is no alternate path, or
the re-homing signaling succeed.
Path exploration requires some signaling between pairs of addresses
to check reachability. An additional protocol may be needed to
perform this task.
In (1,*), the path exploration consists in checking reachability
between each care-of address and each home agent address. If RO mode
is used, the mobile node may also insure reachability between its
correspondent nodes' address(es) and each care-of address.
In (n,*), the path exploration consists in checking reachability
between the home address that is used with the session that must be
re-homed and each care-of address (and optionally with the
correspondent nodes' address(es)). In addition, the session may need
to be re-homed to a different home address. In this case, each path
between a pair (HoA, CoA) must to be validated.
Montavont, et al. Expires November 4, 2008 [Page 17]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
In all these cases the path between the home agent and the
correspondent node is not checked. A specific mechanism may be
defined to check reachability between a home agent and a
correspondent node.
6.1.3. Path Selection
When there exists multiple paths from and to the mobile node, the
mobile node ends up choosing a source address, and possibly the
interface that should be used. A correspondent node that wants to
establish a communication with such a mobile node may end up by
choosing a destination address for this mobile node.
o Interface selection
When the mobile 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 mobile node is out of scope of Mobile IPv6 and might be
implementation specific. On the other hand, if the mobile node
wishes to influence how preferences are set on distant nodes
(correspondent node or home agent), mechanisms such as those
proposed in draft-soliman-flow-binding [9] could be used.
o Home Address Selection
When multiple home addresses are available, the mobile node and
its communicating peers (home agent and correspondent nodes) must
be able to select the appropriate home address 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
selection, such as "Default Address Selection for IPv6" (RFC3484)
[10] or DNS SRV Protocol (RFC2782) [11] 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 in RFC3484 may be defined for home address selection.
Montavont, et al. Expires November 4, 2008 [Page 18]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
o CoA Selection
When multiple care-of addresses are available, the mobile node and
its communicating peers must be able to select the appropriate
care-of address to be used for a particular packet or flow. The
mobile node may use its internal policies to (i) distribute its
flow, and (ii) distribute policies on distant nodes to allow them
to select the preferred care-of address. Solutions like [12] or
[13] may be used.
Another related aspect of path selection is the concern of ingress
filtering. This is covered below in Section 6.1.5.
6.1.4. Rehoming
Re-homing takes place after an outage has been detected or an
alternative path has been identified (see previous issues
Section 6.1.1, Section 6.1.2 and Section 6.1.3), therefrom diverting
existing sessions from one path to another. 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 re-homing or flow redirection is explained in Appendix A
The different mechanisms that can be used to provide re-homing can be
split into three categories, depending on the part of the path that
needs to be changed.
The first category is the care-of address changes : it influences the
path between the mobile node and its home agent, and the path between
the mobile node and its correspondent node in RO mode. This may hold
in case (n, n).
The second category is when the home address changes (: it influences
the entire path. As the home address is the address shown to the
higher layer (above layer 3), an additional mechanism is needed to
manage this change. Solution with a shim layer (e.g., Shim6 [14]),
or solution at the transport layer such as SCTP [5] may be useful.
The third category is when the home agent address changes. In this
case, the bidirectional tunnel between the mobile node and its home
agent as to be switched to the new address of the home agent. This
can be managed transparently by Mobile IPv6 if the home address
doesn't change at the same time. Otherwise, sessions continuity is
not ensured, as explained in the above paragraph.
Montavont, et al. Expires November 4, 2008 [Page 19]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
6.1.5. Ingress Filtering
Ingress filtering mechanisms [15][16] may drop the outgoing packets
when multiple bi-directional tunnels end up at different home agents.
This could particularly occur if different prefixes are handled by
different home agents. If a packet with a source address configured
from a specific prefix is tunneled to a home agent that does not
handle that specific prefix, the packet may be discarded either by
the home agent or by a border router in the home network. The
problem of ingress filtering however, is two-fold. It can occur in
the access network as well as the home network.
Suppose the mobile node selects the interface (which would determine
the care-of address) and the home network (which would determine the
home address): the chosen care-of address may not be registered with
the chosen home address. For instance, consider Figure 2 below. In
the access network, the mobile node MN must use CoA=PA.MN when it
sends packets through AR-A and it must use CoA=PB.MN when it sends a
packet through AR-B. In the home network, it must use HoA=P1.MN when
it tunnels the packet to home agent HA-1, and it must use HoA=P2.MN
when it tunnels the packet to home agent HA-2. To avoid ingress
filtering, the choice is thus limited to a of valid (HoA,CoA) pairs.
This issue is related to Section 6.1.3 and greatly limits the way
mobile node can benefit from its multihoming configuration
(particularly in case of the home agent failure since flows cannot be
diverted to the other home agent).
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
Should the mobile node be able to bind both care-of addresses PA.MN
and PB.MN simultaneously to home addresses P1.MN and P2.MN
respectively (see Section 6.2.1), it would be able to choose the
(HoA,CoA) pair based on the access network it wishes to use for
outgoing packets. It is, nonetheless, still limited to transmit all
packets to a specific home agent for the selected (HoA,CoA) pair,
i.e. ingress filtering at the home network remains unsolved).
Ingress filtering in the home network concerns only the (n,n) case
Montavont, et al. Expires November 4, 2008 [Page 20]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
since the choice of the home and care-of addresses is limited to a
single (HoA, CoA) pair in other cases. In (n,n), the mobile node may
be connected to multiple access networks or multiple home networks
each practicing ingress filtering. To overcome this, mechanisms such
as those provided by Shim6 (see RFC3582 [17] and [14]) may be used.
6.2. MIPv6-specific Issues
6.2.1. Binding Multiple CoAs to a given HoA
In the (1,n) cases, multiple care-of addresses would be available to
the mobile node. In order to use them simultaneously, the mobile
node must be able to bind and register multiple care-of addresses for
a single home address with both the home agent and the correspondent
nodes. The Mobile IPv6 specification is currently lacking such
ability.
Although in the (n,n) cases, Mobile IPv6 allows the mobile node to
have multiple (HoA,CoA) pairs, the upper layer's choice of using a
particular home address would mean that the mobile node is forced to
use the corresponding care-of address. This constrains the mobile
node from choosing the best (in terms of cost, bandwidth etc) access
link for a particular flow, since care-of address is normally bound
to a particular interface. If the mobile node can register all
available care-of addresses with each home address, this would
completely decouple the home address from the interface, and allow
the mobile node to fully exploit its multihoming capabilities.
To counter this issue, a solution like [18] may be used. However,
with simultaneous binding support, there exists a possibility that a
malicious mobile node can successfully bind a number of victims'
addresses as valid care-of addresses for the mobile node with its
home agent. This is further elaborated in [19]. In view of such
risk, it might be avisable for home agent implementations to employ
some form of care-of addresses verification before using the care-of
addresses as a valid routing path to mobile node when accepting
multiple care-of address registrations.
6.2.2. Simultaneous Location in Home and Foreign Networks
Rule 4 of RFC3484 (section 5) specifies that a home address should be
preferred to a care-of address. While this rule allows the host to
choose which address to use, it does not allow the mobile node to
benefit from being multihomed in a situation where it may have one of
its interfaces directly connected to a home link. That is, addresses
from other interfaces cannot be registered as care-of addresses for
the home address associated to the home link the mobile node is
connected to. As a result, flows cannot be redirected transparently
Montavont, et al. Expires November 4, 2008 [Page 21]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
from one care-of address to another and Mobile IPv6 features can only
recover the failure of the home address.
In the 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 home agent.
This issue is currently being resolved by [18].
6.2.3. HA Synchronization
For a single home address obtained from a single home network, when a
failure is affecting ongoing sessions on a given home agent (i.e.
home agent has failed or is overloaded), solutions like [6] may be
used to allowing existing sessions to be shifted from one home agent
to another. However, in the (n,*) cases where home addresses may be
obtained from different home agents on different home networks, such
coordination is not currently available. To achieve a global home
agent synchronization, it might be necessary to extend mechanisms
such as proposed in [6], [20] and [21].
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 Mobile IPv6 implementations are more "friendly" to
multihoming, particularly the use of multiple interfaces. These
implementation-related considerations are described in the sub-
sections below.
6.3.1. Using one HoA as a CoA
In (n,*) cases, the mobile node has multiple home addresses. A home
address may be seen as a care-of address from the perspective of
another home link of the same mobile node.
As an example, a mobile node has two home addresses (HoA1 and HoA2)
on two distinct home links. The mobile node is connected to these
two home links via two interfaces. When the mobile node looses its
connectivity on its first interface and HoA1 is not reachable, it may
want to register HoA2 as a care-of address for HoA1 in order to keep
receiving packets intended to HoA1, via the second interface.
According to the definition of a care-of address, the current Mobile
IPv6 specification does not prohibit to register a home address as
the care-of address from the perspective of another home address.
In RFC3775 section 6.1.7 it is written: "Similarly, the Binding
Montavont, et al. Expires November 4, 2008 [Page 22]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
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 order to benefit from any multihoming configuration, a mobile node
must be able to register whatever address it owns with any of its
home address, as long as the above statement is observed.
6.3.2. Binding a new CoA to the Right HoA
In the (n,*) cases, the mobile node has multiple home addresses.
When the mobile node moves and configures a new care-of address, the
newly obtained care-of address must be bound to a specific home
address. The current Mobile IPv6 specification doesn't provide a
decision mechanism to determine to which home address this newly
acquired care-of address should be bound to.
With no such mechanism, the mobile node may be confused and may bind
this care-of address to a possibly wrong home address. The result
might be to bind the care-of address to the same home address the
previous care-of address 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.3. Binding HoA to interface
In (n,*) cases, Mobile IPv6 does not provide any information on how
home addresses should be bound to a device, and particularly there is
no mechanism to bind home addresses to interfaces.
This may be troublesome, for example, when we consider a mobile node
configured with two home addresses and equipped with three
interfaces. When the mobile node is connected to a home link via one
interface, it will need to bind the corresponding home address to
this interface, even if the home address was initially assigned to
another one.
HoA1 HoA2
CoA1 CoA2 CoA3
Iface1 Iface2 Iface3
Figure 3: Illustration of the case (2,3)
Home address must always be assigned to an activated interface and if
the mobile node is connected to its home link, the corresponding home
Montavont, et al. Expires November 4, 2008 [Page 23]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
address must be used on this interface. In some cases, the home
address then would have to be re-assigned to another interface in
case of connection loss or attachment to the home link.
6.4. Summary
The table below summarizes the cases where each issue applies.
+==========================================================+
| # of HoAs: | 1 | 1 | n | n | n |
| # of CoAs: | 1 | n | 0 | 1 | n |
+==========================================================+
| General IPv6 Issues |
+--------------------------------------+---+---+---+---+---+
| Failure Detection | o | o | ? | o | o |
+--------------------------------------+---+---+---+---+---+
| Path Exploration | | | | | |
+--------------------------------------+---+---+---+---+---+
| Path Selection | | o | ? | o | o |
+--------------------------------------+---+---+---+---+---+
| Flow Redirection | o | o | ? | o | o |
+--------------------------------------+---+---+---+---+---+
| Ingress Filtering | | | ? | o | o |
+--------------------------------------+---+---+---+---+---+
| MIPv6-Specific Issues |
+--------------------------------------+---+---+---+---+---+
| Binding Multiple CoAs to a given HoA | | o | ? | o | o |
+--------------------------------------+---+---+---+---+---+
| Simultaneous Location in Home and | | o | ? | o | o |
| Foreign Networks | | | | | |
+--------------------------------------+---+---+---+---+---+
| HA Synchronization | | | | | |
+--------------------------------------+---+---+---+---+---+
| Implementation-Related Concerns |
+--------------------------------------+---+---+---+---+---+
| Using one HoA as a CoA | | | ? | o | o |
+--------------------------------------+---+---+---+---+---+
| Binding a new CoA to the Right HoA | | | ? | o | o |
+--------------------------------------+---+---+---+---+---+
| Binding HoA to Interface(s) | o | o | ? | o | o |
+==========================================================+
Figure 4: Summary of Issues and Categorization
Montavont, et al. Expires November 4, 2008 [Page 24]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
7. Conclusion
In this document, we have demonstrated issues arising for multihomed
mobile nodes operating Mobile IPv6. We have seen that mechanisms are
needed:
o to redirect flows from a failed path to a new path,
o to decide which path should better be taken when multiple paths
are available,
o to register multiple care-of addresses
o to exchange policies between the mobile node and the home agent
Even if Mobile IPv6 can be used as a mechanism to manage multihomed
mobile nodes, triggers of flow redirection between interfaces/
addresses are not adapted to the multihoming status of the node.
Also, we have shown that in some configurations Mobile IPv6 is
ambiguous in the definitions of CoA/HoA and in the mappings between
home addresses, care-of addresses and network interfaces. Finally,
we have also raised issues not directly related to Mobile IPv6, but
solutions for these issues are needed for mobile nodes to fully take
advantage of their multihomed configuration.
8. IANA Considerations
This is an informational document and as such does not require any
IANA action.
9. Security Considerations
This is an informational document where the multihoming
configurations under the operation of Mobile IPv6 are analyzed.
Security considerations of these multihoming configurations, should
they be different from those that concern Mobile IPv6, must be
considered by forthcoming solutions. For instance, Section 6.2.1
described a potential threat that should be considered when
developing a proposed solution for multiple care-of addresses
registration.
10. Contributors
The following people have contributed ideas, text and comments to
earlier versions of this document: Eun Kyoung Paik from Seoul
Montavont, et al. Expires November 4, 2008 [Page 25]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
National University, South Korea and Thomas Noel from Universite
Louis Pasteur, Strasbourg, France.
11. Acknowledgments
The authors would like to thank all the people who have sent comments
so far, particularly Marcelo Bagnulo, Romain Kuntz, Tobias Kufner,
Henrik Levkowetz, George Tsirtsis for their in-depth comments and
raising new issues.
12. References
12.1. Normative 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., Ng, C., and K.
Kuladinithi, "Motivations and Scenarios for Using Multiple
Interfaces and Global Addresses",
draft-ietf-monami6-multihoming-motivation-scenario-03 (work in
progress), May 2008.
[4] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
Paxson, "Stream Control Transmission Protocol", RFC 2960,
October 2000.
12.2. Informative References
[6] Wakikawa, R., "Home Agent Reliability Protocol",
draft-ietf-mip6-hareliability-03 (work in progress),
November 2007.
[7] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment
in IPv6", RFC 4135, August 2005.
[8] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S., and
A. Yegin, "Link-Layer Event Notifications for Detecting Network
Montavont, et al. Expires November 4, 2008 [Page 26]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
Attachments", RFC 4957, August 2007.
[9] Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi,
"Flow Bindings in Mobile IPv6 and Nemo Basic Support",
draft-soliman-monami6-flow-binding-05 (work in progress),
November 2007.
[10] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[11] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[12] Larsson, C., Eriksson, M., Mitsuya, K., Tasaka, K., and R.
Kuntz, "Flow Distribution Rule Language for Multi-Access
Nodes", draft-larsson-mext-flow-distribution-rules-00 (work in
progress), November 2007.
[13] Mitsuya, K., "A Policy Data Set for Flow Distribution",
draft-mitsuya-monami6-flow-distribution-policy-04 (work in
progress), August 2007.
[14] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim
Protocol for IPv6", draft-ietf-shim6-proto-10 (work in
progress), February 2008.
[15] 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.
[16] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[17] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
Multihoming Architectures", RFC 3582, August 2003.
[18] Wakikawa, R., Ernst, T., Nagami, K., and V. Devarapalli,
"Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-07 (work in progress),
April 2008.
[19] Lim, B., Ng, C., and K. Aso, "Verification of Care-of Addresses
in Multiple Bindings Registration",
draft-lim-mext-multiple-coa-verify-01 (work in progress),
February 2008.
[20] Wakikawa, R., Devarapalli, V., and P. Thubert, "Inter Home
Montavont, et al. Expires November 4, 2008 [Page 27]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work
in progress), February 2004.
[21] Koh, B., Ng, C., and J. Hirano, "Dynamic Inter Home Agent
Protocol", draft-koh-mip6-nemo-dhap-00 (work in progress),
July 2004.
Appendix A. Why a MN may want to redirect flows
When a mobile node 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
mobile node to redirect flow from one address to another:
o Failure detection: the path between the mobile node and its
correspondent node(s) is broken. The failure can occur at
different places onto this path; The failure can be local on the
mobile node, where the interface used on the mobile node 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 mobile node and one of
its home agent. Yet another alternative is that the failure can
be on the path between the home agent and the correspondent node.
If route optimization is used, it can also be a failure between
the mobile node and its correspondent node(s).
o New address: a new address on the mobile node may become
available, e.g. when the mobile node connects to the network with
a new interface. The mobile node 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 mobile node
is mobile, it may have to change its point of attachment. When a
mobile node performs a horizontal handover, the handover latency
(the time during which the mobile node can not send nor receive
packets) can be long and the flows exchanged on the interface can
be interrupted. If the mobile node 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 [8].
o Change in the network capabilities: the mobile node can observe a
degradation of service on one of its interface, or conversely an
improvement of capacity on an interface. The mobile node may then
Montavont, et al. Expires November 4, 2008 [Page 28]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
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
mobile node and a correspondent node. According to internal
policies, the mobile node may want to redirect this flow on a most
suitable interface.
Authors' Addresses
Nicolas Montavont
Institut Telecom - Telecom Bretagne
2, rue de la chataigneraie
Cesson Sevigne 35576
France
Phone: (+33) 2 99 12 70 23
Email: nicolas.montavont@telecom-bretagne.eu
URI: http://www.rennes.enst-bretagne.fr/~montavont/
Ryuji Wakikawa
Toyota ITC / Keio University
6-6-20 Akasaka, Minato-ku
Tokyo 107-0052
Japan
Phone: +81-3-5561-8276
Fax: +81-3-5561-8292
Email: ryuji@jp.toyota-itc.com
Thierry Ernst
INRIA
INRIA Rocquencourt
Domaine de Voluceau B.P. 105
Le Chesnay, 78153
France
Phone: +33-1-39-63-59-30
Fax: +33-1-39-63-54-91
Email: thierry.ernst@inria.fr
URI: http://www.nautilus6.org/~thierry
Montavont, et al. Expires November 4, 2008 [Page 29]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
Singapore
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 November 4, 2008 [Page 30]
Internet-Draft Analysis of Multihoming in MIPv6 May 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
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.
Montavont, et al. Expires November 4, 2008 [Page 31]
