MONAMI6 Working Group N. Montavont
Internet-Draft GET/ENST-B
Intended status: Informational R. Wakikawa
Expires: January 11, 2008 Keio University
T. Ernst
INRIA
C. Ng
Panasonic Singapore Labs
K. Kuladinithi
University of Bremen
July 10, 2007
Analysis of Multihoming in Mobile IPv6
draft-ietf-monami6-mipv6-analysis-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 11, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Montavont, et al. Expires January 11, 2008 [Page 1]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
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,
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.
Montavont, et al. Expires January 11, 2008 [Page 2]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Goals and Node Capabilities . . . . . . . . . . . . . . . . . 9
4. Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Multihoming Configurations . . . . . . . . . . . . . . . . . . 13
5.1. (1,1): 1 HoA, 1 CoA . . . . . . . . . . . . . . . . . . . 13
5.2. (n,1): n HoAs, 1 CoA . . . . . . . . . . . . . . . . . . . 14
5.3. (1,n): 1 HoA, n CoAs . . . . . . . . . . . . . . . . . . . 16
5.4. (n,n): n HoAs, n CoAs . . . . . . . . . . . . . . . . . . 17
5.5. (n,0): n HoAs, no CoAs . . . . . . . . . . . . . . . . . . 18
6. Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 19
6.1. General IPv6-related Issues . . . . . . . . . . . . . . . 19
6.1.1. Failure Detection . . . . . . . . . . . . . . . . . . 19
6.1.2. Path Exploration . . . . . . . . . . . . . . . . . . . 19
6.1.3. Path Selection . . . . . . . . . . . . . . . . . . . . 20
6.1.4. Rehoming . . . . . . . . . . . . . . . . . . . . . . . 21
6.1.5. Ingress Filtering . . . . . . . . . . . . . . . . . . 22
6.2. MIPv6-specific Issues . . . . . . . . . . . . . . . . . . 23
6.2.1. Binding Multiple CoAs to a given HoA . . . . . . . . . 23
6.2.2. Simultaneous Location in Home and Foreign Networks . . 23
6.2.3. HA Synchronization . . . . . . . . . . . . . . . . . . 24
6.3. Considerations for MIPv6 Implementation . . . . . . . . . 24
6.3.1. Using one HoA as a CoA . . . . . . . . . . . . . . . . 24
6.3.2. Binding a new CoA to the Right HoA . . . . . . . . . . 25
6.3.3. Binding HoA to interface . . . . . . . . . . . . . . . 25
6.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 26
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . . 32
Montavont, et al. Expires January 11, 2008 [Page 3]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
Appendix A. Why a MN may want to redirect flows . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 37
Montavont, et al. Expires January 11, 2008 [Page 4]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
1. Introduction
The emergence of performant wireless technologies has favored node
mobility within the Internet. Nowadays, and even more tomorrow,
nodes are highly mobile and can change their point of attachment to
the Internet at any time, even during active network connections. As
such, Mobile IPv6 (RFC 3775 [1] and RFC 3776 [2]) allows mobile nodes
to maintain sessions open while changing their point of attachment to
the Internet.
Besides - 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 shall 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 thus 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, the reader shall read 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
shall also understand the operation of the Mobile IPv6 protocol
(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 January 11, 2008 [Page 5]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
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.
Montavont, et al. Expires January 11, 2008 [Page 6]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
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 MN
a Mobile Node operating MIPv6
o HA
a Mobile IPv6 Home Agent
o HoA
a Mobile IPv6 Home Address
o CoA
a Mobile IPv6 Care-of Address
o Multihomed MN
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 MIPv6, this may
translate into the following definition:
A MN is said multihomed when it has either i) multiple addresses
which are used as source addresses or ii) multiple tunnels to
transmit packets, or both.
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
Montavont, et al. Expires January 11, 2008 [Page 7]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
attached to (presumably) distinct foreign links.
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 MN is using multiple addresses simultaneously when an incoming
packet with the destination address set to any of these addresses
reaches the MN, or when any of these addresses can be used by the
MN as the source address of outcoming packets.
o Simultaneously using multiple interfaces
A MN is using multiple interfaces simultaneously when it can
transmit IP packets over any of these interfaces.
o BT Mode
MIPv6 Bidirectional tunnel between MN and HA.
o RO Mode
MIPv6 Route optimization between MN and CN.
Montavont, et al. Expires January 11, 2008 [Page 8]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
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,
inteface switching, preference settings, and aggregate bandwidth.
These do somwhat 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 MN as long as at
least one path is maintained between the MN and the fixed Internet.
This path can be divided into two portions: the path between the MN
and 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 guaranteed. 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 MN and its CN.
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.,
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.
Montavont, et al. Expires January 11, 2008 [Page 9]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
3. A MN allocated with multiple valid addresses must be able to use
them simultaneously.
4. A MN equipped with multiple interfaces (attached to distinct
foreign links or distinct home links, or a combination of both)
must be able to use them simultaneoulsy.
5. A MN should be able to distribute its traffic load among its
valid global addresses.
6. If multiple HAs are available to manage bindings for a given HoA,
the MN should be able to use them 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 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 January 11, 2008 [Page 10]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
4. Taxonomy
In order to examine the issues preventing a MN 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
HoAs is independent from it having multiple interfaces. Having
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 the node to configure several CoAs on
that link.
Montavont, et al. Expires January 11, 2008 [Page 11]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
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 HoAs and
CoAs, different policies will be needed, such as "which CoA has to be
mapped to which HoA", "must all the CoAs be mapped with all the
HoAs", etc.
Montavont, et al. Expires January 11, 2008 [Page 12]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
5. Multihoming Configurations
In this section, we detail all the possible multihoming
configurations. For each one, we briefly explain how it may happen.
We also list which of the goals outlined in Section 3 are achievable
provided that supporting mechanisms are either already existing or
could be added. 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 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 MN 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 MN in this configuration with only a single network interface is
not multihomed. This configuration is the common case of a MN away
from its home link: the node has one HoA and one CoA which is
configured on the foreign link. None of the multihoming goals are
achievable.
A MN in the same configuration but with several interfaces is
multihomed and lead to a special situation where the MN is connected
to both its home link and a foreign link. In order to use both
interfaces simultaneously, the HoA would be directly used on the
interface connected to the home link, and a CoA 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 MN 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. 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.
Current situation with MIPv6 (when the node has multiple interfaces):
o Reliability
Reliability is achievable, but in a limited manner. The MN has
two valid addresses, but is unable to use both addresses
Montavont, et al. Expires January 11, 2008 [Page 13]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
simultaneously: it cannot register the CoA configured on the
foreign network with its HA and receive packets from the HA via a
tunnel to the CoA at the same time it receives packet on the HoA
from the home link. In addition, if the MN looses its connection
established using the CoA on the foreign link, flows must be re-
initiated with another address (either the HoA, or a new CoA
obtained on another foreign link). Fault recovery is thus only
possible without transparency, and MIPv6 features can only recover
the failure of the HoA. This issue is detailed in Section 6.2.2.
However, it might be possible for the MN to register the CoA with
selected CNs (i.e. route optimization). In this case, the MN can
enjoy a better reliability for communications sessions opened with
these CNs. When the CoA fails, the MN can either bind a new CoA,
or remove the binding and directly get the packets to its HoA.
Reliability could also be achieved through bi-casting since the MN
has two addresses and should be able to request any CN to
duplicate traffic to both of them. However, MIPv6 does not allow
the MN to request bi-casting on the CN (see Section 6.2.2).
o Load Sharing, Flow Distribution
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 flow
distribution can be achieved when sessions are initiated by the
MN. When a CN initiates a session 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 the distant
node, load sharing and flow distribution cannot be achieved. See
in Section 6.1.3 where such path selection issues are discussed.
5.2. (n,1): n HoAs, 1 CoA
A MN in this configuration is multihomed since it has several HoAs.
This case may happen when a node gets access to the Internet through
different HAs (possibly distinct operators), each offering a Mobile
IPv6 service to the node. That way, the node would have a HoA per
HA. Alternatively, a single home network may be multihomed to the
Internet, leading to the advertisement of multiple prefixes on the
home link. The MN would thus have multiple HoAs on a single home
link.
In either cases, the node would configure a single CoA on the visited
IPv6 subnet, and bind that single CoA to all its HoAs. If the MN has
Montavont, et al. Expires January 11, 2008 [Page 14]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
multiple interfaces, only one interface is connected to a foreign
network. The other interfaces are connected to their home links, or
are inactive.
Current situation with MIPv6:
o Reliability
In case a HoA fails, the session using the HoA must be restarted
since MIPv6 does not provide any mechanism to hand-over
transparently from a failed HoA to another one. Fault tolerance
cannot be achieved in this case, since established communications
cannot be preserved. See the corresponding discussion in
Section 6.1.4 and Section 6.2.3.
The CoA may change when the MN has multiple interfaces and is
disconnected from its home link (e.g. failure of the interface, or
movement). In such a situation, MIPv6 allows to transparently
redirect flows using the old CoA as a temporarily address (i.e.
the HoA was used as the main address) to another CoA. For
sessions directly opened via the CoA, the loss of the address
implies a re-initiation of the session.
Reliability through bi-casting could also be achieved 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 used as
a CoA bound to the other HoA. (see in Section 6.2.1 and
Section 6.3.1). In conclusion, reliability can only be achieved
in some cases, when flows are initiated via a HoA.
o Load Sharing
In Bidirectional Tunnel (BT) mode, load sharing only affects 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. However, it can be
noted that load sharing on the path between the CN and the HA
might not be the most bandwidth contraint part of the overall path
from the CN to the MN. Thus load sharing might not bring
Montavont, et al. Expires January 11, 2008 [Page 15]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
important benefits. See in Section 6.1.3 where such path
selection issues are discussed. It is also possible that the MN
register one HoA as a CoA for another HoA (see in Section 6.3.1).
o Flow Distribution
This is achievable when the MN 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 MN can spread flows over its
interfaces. Note that if a CN initiates a communication, the
interface that it will use on the MN would depend on the
information it has about this MN.
5.3. (1,n): 1 HoA, n CoAs
A MN in this configuration is multihomed since it has several CoAs.
It may occur when the MN 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 MN may be
connected to its home link.
Current situation with MIPv6:
o Reliability
Reliability support is limited to recover from a failed CoA.
Fault recovery is achieved in MIPv6 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.1), to
check reachability (Section 6.1.2), to determine which CoA should
be used instead (Section 6.1.3) and to redirect flows to the new
CoA (Section 6.1.4).
o Load Sharing and Flow Distribution
This configuration allows to share the load and to 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 and flow distribution 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 to several CoAs at
the same time, the MN or HA/CN must be able to select the
appropriate CoA. This selection could be done based on user/
application preferences (see Section 6.1.3).
Montavont, et al. Expires January 11, 2008 [Page 16]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
5.4. (n,n): n HoAs, n CoAs
A MN 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 MN has several HoAs, e.g. given by different
operators (similar to case (n,1) in Section 5.2) and several CoAs,
e.g. because the node is receiving multiple IPv6 prefixes (similar to
case (1,n) in Section 5.3). 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.
Current situation with MIPv6:
o Reliability
If one CoA becomes unreachable (similar to (1,n)), the MN can
redirect flows to another CoA by associating any of the other
available CoAs to the corresponding HoA. If the MN can not use
one of its HoA anymore (similar to (n,1)), 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 Load Sharing and Flow Distribution
MIPv6 allows the MN to 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 bi-casting is
used) should be bound to which HoA (see Section 6.1.3).
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. This HoA would then be viewed as a
CoA bound to another HoA (similar to (n,1)). MIPv6 does not
prevent this behavior, which allows to set a certain preference on
addresses usage. See Section 6.3.1 for the corresponding issue.
Montavont, et al. Expires January 11, 2008 [Page 17]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
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 HoAs to serve as the CoA
of another HoA (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.
Current situation with MIPv6
o Reliability
If the MN is disconnected from one of its interfaces, the MN
should be able to register another valid HoA as a CoA bound to its
failed HoA (see issue Section 6.3.1).
o Load Sharing, Flow Distribution
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.3 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.3.1). If the MN policies
indicate to redirect only one flow, a supplementary mechanism
would be needed.
Montavont, et al. Expires January 11, 2008 [Page 18]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
6. Multihoming 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 (Section 6.1), and issues that
are specific to MIPv6 (Section 6.2). 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. 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
is broken (i.e., loss of connectivity), the path between the MN and
the HA 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, MIPv6 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).
[5] is addressing such concerns through the use of layer 2 triggers
[6]. 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
MN and its CN(s), as well as between the MN and its HA(s), between
the MN and CN(s), or between the HA and CN(s).
6.1.2. Path Exploration
When the MN 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
Montavont, et al. Expires January 11, 2008 [Page 19]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
to provide bidirectional connectivity between the MN and its HA, and
optionally between the MN and its CN. 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 address to
check reachability. An additional protocol may be needed to perform
this task.
In (1, *), the path exploration consists in checking reachability
between each CoA and each HA address. If RO mode is used, the MN may
also insure reachability between its CNs address(es) and each CoA.
In (n, *), the path exploration consists in checking reachability
between the HoA that is used with the session that must be re-homed
and each CoA (and optionnally with the CN address(es)). In addition,
the session may need to be re-homed to a different HoA. In this
case, each path between a pair (HoA, CoA) must to be validated.
In all these cases the path between the HA and the CN is not checked.
A specific mechanism may be defined to check reachability between a
HA and a CN.
6.1.3. Path Selection
When there exists multiple paths from and to the MN, the MN ends up
choosing a source address, and possibly the interface that should be
used. A CN that wants to establish a communication with such a MN
may end up by choosing a destination address for this MN.
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
draft-soliman-flow-binding [7] could be used.
Montavont, et al. Expires January 11, 2008 [Page 20]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
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
selection, such as "Default Address Selection for IPv6" (RFC3484)
[8] or DNS SRV Protocol (RFC2782) [9] 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 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 may use its
internal policies to (i) distribute its flow, and (ii) distribute
policies on distant nodes to allow them to select the preferred
CoA. Solutions like draft-soliman-flow-binding [7] 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 CoA changes : it influences the path
between the MN and its HA, and the path between the MN and its CN in
RO mode. This may hold in case (n, n).
The second category is when the HoA changes (: it influences the
entire path. As the HoA is the address shown to the higher layer
Montavont, et al. Expires January 11, 2008 [Page 21]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
(above layer 3), an additional mechanism is needed to manage this
change. Solution with a shim layer (e.g., Shim6 [REF shim6 TO BE
ADDED]), or solution at the transport layer such as SCTP [REF SCTP TO
BE ADDED] may be useful.
The third category is when the HA address changes. In this case, the
bidirectional tunnel between the MN and its HA as to be switched to
the new address of the HA. This can be managed transparently by
MIPv6 if the HoA doesn't change at the same time. Otherwise,
sessions continuity is not ensured, as explained in the above
paragraph.
6.1.5. Ingress Filtering
Ingress filtering mechanisms [10][11] may drop the outgoing packets
when multiple bi-directional tunnels end up at different HAs. This
could particularly occur if different prefixes are handled by
different HAs. If a packet with a source address configured from a
specific prefix is tunneled to a HA that does not handle that
specific prefix, the packet may be discarded either by the HA 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 MN selects the interface (which would determine the CoA) and
the home network (which would determine the HoA): the chosen CoA may
not be registered with the chosen HoA. For instance, consider
Figure 2 below. In the access network, the 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 greatly
limits the way MN can benefit from its multihoming configuration
(particularly in case of the HA failure since flows cannot be
diverted to the other HA).
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 +------+ +----------+ +------+
Montavont, et al. Expires January 11, 2008 [Page 22]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
Figure 2: MN connected to Multiple Access/Home Networks
Should the MN be able to bind both CoAs PA.MN and PB.MN
simultaneously to HoAs 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 HA
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
since the choice of the HoA and CoA is limited to a single (HoA, CoA)
pair in other cases. In (n,n), the MN 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 [12] and [13]) may be used.
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,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, a solution like [14] may be used.
6.2.2. Simultaneous Location in Home and Foreign Networks
Rule 4 of RFC3484 (section 5) specifies that a HoA should be
preferred to a CoA. While this rule allows the host to choose which
address to use, it does not allow the MN 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 CoAs for the HoA associated to the
home link the mobile node is connected to. As a result, flows cannot
be redirected transparently from one CoA to another and MIPv6
Montavont, et al. Expires January 11, 2008 [Page 23]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
features can only recover the failure of the HoA.
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.2.3. HA Synchronization
In the (n,*) cases, HoAs may be obtained from different HAs. If any
failure is affecting ongoing sessions on a given HoA (HA has failed
or is overloaded), there is currently no failover allowing existing
sessions to be shifted from one HA to another tough certain level of
co-ordination between HAs on registered bindings would be useful.
This co-ordination could further be extened to all (*,*) cases where
distinct HAs would be co-ordinated to register CoAs for the same HoA.
HA synchronization mechanisms such as these described in [15] and
[16] could be used.
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
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 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.
MN looses its connectivity on its first interface and 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
does not prohibit to register a HoA as the CoA from the perspective
of another HoA.
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
Montavont, et al. Expires January 11, 2008 [Page 24]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
entries)."
In order to benefit from any multihoming configuration, a MN must be
able to register whatever address it owns with any of its HoA, as
long as the above statement is observed.
6.3.2. 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.3. Binding HoA to interface
In (n,*) cases, MIPv6 does not provide any information on how HoAs
should be bound to a device, and particularly there is no mechanism
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.
Montavont, et al. Expires January 11, 2008 [Page 25]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
6.4. Summary
The table below summarizes the cases where each issue applies (TO BE
CHECKED AND COMPLETED)
+=====================================================+
| # 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 | | o | ? | o | o |
| given HoA | | | | | |
+---------------------------------+---+---+---+---+---+
| Simultaneous location in home | | o | ? | o | o |
| and foreign networks | | | ? | | |
+---------------------------------+---+---+---+---+---+
| HA Synchronization | | | | | |
+---------------------------------+---+---+---+---+---+
| Implementation-Related Concerns |
+---------------------------------+---+---+---+---+---+
| Using one HoA as a CoA | | | ? | o | o |
+---------------------------------+---+---+---+---+---+
| Binding a new CoA to the | | | ? | o | o |
| right HoA | | | | | |
+---------------------------------+---+---+---+---+---+
| Binding HoA to interface(s) | o | o | ? | o | o |
+=====================================================+
Figure 4: Summary of Issues and Categorization
Montavont, et al. Expires January 11, 2008 [Page 26]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
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 Router 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
HoAs, CoAs 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.
Montavont, et al. Expires January 11, 2008 [Page 27]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
8. IANA Considerations
This is an informational document and as such does not require any
IANA action.
Montavont, et al. Expires January 11, 2008 [Page 28]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
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.
Montavont, et al. Expires January 11, 2008 [Page 29]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
10. Contributors
The following people have contributed ideas, text and comments to
earlier versions of this document: Eun Kyoung Paik from Seoul
National University, South Korea and Thomas Noel from Universite
Louis Pasteur, Strasbourg, France.
Montavont, et al. Expires January 11, 2008 [Page 30]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
11. Acknowledgments
The authors would like to thank all the people who have sent comments
so far, particularly Tobias Kufner, Marcelo Bagnulo, Romain Kuntz and
Henrik Levkowetz for their in-depth comments and raising new issues.
Montavont, et al. Expires January 11, 2008 [Page 31]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
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-01 (work in
progress), October 2006.
[4] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
12.2. Informative References
[5] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment
in IPv6", RFC 4135, August 2005.
[6] Krishnan, S., Montavont, N., Yegin, A., Veerepalli, S., and A.
Yegin, "Link-layer Event Notifications for Detecting Network
Attachments", draft-ietf-dna-link-information-06 (work in
progress), February 2007.
[7] Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi,
"Flow Bindings in Mobile IPv6",
draft-soliman-monami6-flow-binding-04 (work in progress),
February 2007.
[8] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[9] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[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] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
Montavont, et al. Expires January 11, 2008 [Page 32]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
[12] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
Multihoming Architectures", RFC 3582, August 2003.
[13] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim
protocol", draft-ietf-shim6-proto-08 (work in progress),
May 2007.
[14] Wakikawa, R., Ernst, T., Nagami, K., and V. Devarapalli,
"Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-02 (work in progress),
March 2007.
[15] Wakikawa, R., Devarapalli, V., and P. Thubert, "Inter Home
Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work
in progress), February 2004.
[16] Koh, B., Ng, C., and J. Hirano, "Dynamic Inter Home Agent
Protocol", draft-koh-mip6-nemo-dhap-00 (work in progress),
July 2004.
Montavont, et al. Expires January 11, 2008 [Page 33]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
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 may become available, e.g.
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
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
[6] .
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 January 11, 2008 [Page 34]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
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.org/
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 January 11, 2008 [Page 35]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
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 January 11, 2008 [Page 36]
Internet-Draft Analysis of Multihoming in MIPv6 July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Montavont, et al. Expires January 11, 2008 [Page 37]
