IETF MIP6 Working Group N. Montavont
Internet-Draft LSIIT - ULP
Expires: July 11, 2005 R. Wakikawa
Keio University
T. Ernst
WIDE at Keio University
T. Noel
LSIIT - ULP
C. Ng
Panasonic Singapore Labs
January 10, 2005
Analysis of Multihoming in Mobile IPv6
draft-montavont-mobileip-multihoming-pb-statement-03.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 July 11, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Montavont, et al. Expires July 11, 2005 [Page 1]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005
The use of multiple interfaces is foreseen to provide ubiquitous,
permanent and fault-tolerant access to the Internet, particularly on
mobile nodes which are more subject to failure or sudden lacks of
connectivity. However, Mobile IPv6 currently lacks support for such
multihomed nodes. Individual solutions have been proposed to extend
Mobile IPv6 but all issues have not been addressed in a single
document. The purpose of the present document is thus to fill up
this gap and to raise the discussion in order to make sure that
forthcoming solutions will address all the issues. In this document,
we propose a taxonomy to classify the situations where a mobile node
could be multihomed. This taxonomy is then used to highlight the
issues preventing mobile nodes operating Mobile IPv6 to be
multihomed.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9
6.1 Deciding which HoA a new CoA should be bound to . . . . . 9
6.2 Binding Multiple CoAs to a HoA . . . . . . . . . . . . . . 10
6.3 Using one HoA as a CoA . . . . . . . . . . . . . . . . . . 10
6.4 Using multiple interfaces simultanouely . . . . . . . . . 10
6.5 Relationship between interfaces and HoAs . . . . . . . . . 10
6.6 Flow redirection . . . . . . . . . . . . . . . . . . . . . 11
6.7 Flows filtering . . . . . . . . . . . . . . . . . . . . . 11
6.8 Multiple HoAs . . . . . . . . . . . . . . . . . . . . . . 12
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 16
Montavont, et al. Expires July 11, 2005 [Page 2]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005
1. Introduction
The use of multiple addresses (allocated to either a single interface
or multiple interfaces) is foreseen to provide ubiquitous, permanent
and fault-tolerant access to the Internet, particularly on mobile
nodes which are prone to failure or sudden lacks of connectivity.
Mobile IPv6 [1],[2] is designed to allow a mobile node to maintain
its IPv6 communications while moving between IPv6 subnets. However,
the current specification of Mobile IPv6 lacks support for mobile
nodes with multiple addresses used simultaneously, i.e. multihomed
mobile nodes. These addresses would be assigned to a single
interface or to multiple interfaces, which poses a number of issues.
Individual solutions have been proposed to extend Mobile IPv6 for
multihomed mobile nodes, but all issues have not been addressed in a
single document. The purpose of the present document is thus to fill
up this gap by listing such issues, raising the discussion at the
IETF, and placing some requirements in order to propose comprehensive
solutions in forthcoming standards.
This document has two goals. The first goal of this document is to
define the requirements from the point of view of multihomed mobile
nodes operating Mobile IPv6. The second goal of this document is to
define the issues araising when we attempt to fullfil these
requirements. The definition of the potentially needed solutions is
out of scope of the analysis document. These should be defined in a
separate document once the IETF community agrees on which issues
should be solved.
In order to reach the goals of this document, we define a taxonomy
which is used to describe the different situations where a mobile
node is multihomed. For each case, we show the configuration a
multihomed node may have (number of interfaces, number of Home
Addresses or number of Care-of Addresses). We also illustrate each
scenario.
To understand the foundation of this document, the reader must read
our companion document [3] which outlines the motivations, the goals
and the benefits of multihoming for both fixed and mobile nodes (i.e.
generic IPv6 nodes). Real-life scenarios as illustrated in that
document are the base motivations of the present study. The reader
must also understand the operation of the Mobile IPv6 protocol ([1]).
The document is organized as follows: in the first section, we
introduce terminology related to multihoming. Then we propose a
taxonomy to classify the different cases where mobile nodes are
multihomed. We then present requirements for multihomed MN.
Thereafter the taxonomy is used to describe the multihoming scenarios
specific to Mobile IPv6. Finaly we list all open issues related to a
Montavont, et al. Expires July 11, 2005 [Page 3]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005
multihomed MN and identify what is missing to reach goals fixed in
[3].
2. Terminology
The terms used in the present document are defined in [4], [1] and
[3]. From now on we will use the abbreviations MIP6 for Mobile IPv6
and MN for a "Mobile Node operating MIP6".
In [3], a node is said to be multihomed when it has multiple IPv6
addresses, either because multiple prefixes are advertised on the
link(s) the node is attached to, or because the node has multiple
interfaces (see the entire definition).
For a mobile node operating MIP6, this may translate into the MN
having multiple HoAs and/or multiple CoAs:
o A MN would have multiple HoAs if multiple prefixes are advertised
on the home link or if it has multiple interfaces named on
(presumably) distinct home links.
o A MN would have multiple CoAs if multiple prefixes are advertised
on the foreign link or if it has multiple interfaces attached to
(presumably) distinct foreign links.
A valid address is an address topologically correct (it is named
after the prefix advertised on the link the interface is attached to)
and routable.
A MN is said to be "simultaneously using multiple addresses" if the
MN has the ability to use any of the said multiple addresses at the
same time. This implies that the MN is able to receive packets with
destination address field equals to any of the said multiple
addresses, and the MN is able to choose any of the said multiple
addresses as the source address of the packets it is sending.
A MN is said to be "simultaneously using multiple interfaces" if
there is at least one valid address named for each of the said
multiple interfaces, and that the MN is able to simultaneously use
these addresses.
3. Taxonomy
In order to aid the discussion of the benefits of multihoming as
listed in [3] from the perspective of a mobile node, we will use the
following taxonomy in this document:
Montavont, et al. Expires July 11, 2005 [Page 4]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005
o x = number of active interfaces
o y = number of Home Addresses (HoAs)
o z = 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. An illustration of this taxonomy is given in Figure
1.
Mobile Node
HoA1 HoA2 ... HoAn --> Mobile IP layer (y)
| | |
+-----+--------+ | |
| | | | |
CoA1 +--CoA2 +---CoA3 ... CoAn --> IP layer (z)
| | | |
Link1 Link2 Link3 ... Linkn --> IPv6 Link (n/a *)
| | | |
+-----+----+ | |
| | |
IF1 IF2 ... IFn --> Physical layer (x)
HoA1 ::= {CoA1, 2, 3} [IF1 and IF2]
HoA2 ::= {CoA3} [IF2]
Mobile Node(x = 2, y = 2, z = 3)
* because number of IPv6 link is equal to the number of CoAs, equal to y
Figure 1: Illustration of the Taxonomy
The variable y indicates the number of HoAs allocated to a node. A
node may have multiple HoAs (y=n) when either:
o The node has only one home link, and all its HoAs are based on the
same IPv6 prefix (e.g. the node may have multiple interfaces).
o The node has only one home link, and multiple HoAs with distinct
prefixes because there are several IPv6 prefixes advertised on the
home link.
o The node has several home links, and thus has at least two HoAs
with different IPv6 prefixes.
As the taxonomy suggests, the fact that the mobile node has several
Montavont, et al. Expires July 11, 2005 [Page 5]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005
HoAs is independent from the fact that the mobile node has multiple
interfaces. The fact that the mobile node has multiple interfaces
does not imply that it has multiple HoAs and vice-versa.
We propose a taxonomy with three parameters because each of them has
an influence on either the mobile node behavior / management, or the
potential benefits the mobile node may obtain from such
configuration. According to the number of interfaces, a mobile node
can indeed expect different benefits. If several interfaces are
available, they can for instance be used simultaneouly to save
bandwidth. If only one interface is available at a time but the node
is still multihomed, multiple source / destination addresses or
multiple HAs may be used according to the type of traffic. This
feature could also allow load balancing.
The number of HoAs and CoAs help to consider all scenarios of
multihomed nodes. These parameters will have an impact on the way
multihoming is supported. According to the number of HoAs and CoAs,
different policies will be needed, such as which CoA have to be
mapped with which HoA, do all the CoAs need to be mapped with all the
HoAs, etc.
4. Requirements
To achieve the benefits of multihoming as described in [3], some
requirements on the MN might have to be fulfilled. These include:
o The MN must have a valid address on each link an interface is
attached to.
o The MN must have either multiple interfaces with at least a single
valid IP address on each interface, or a single interface with
more than one valid address.
o A MN equipped with multiple interface must be able to use multiple
interfaces simultaneously.
o A MN quipped with multiple interfaces must be able to attach
distinct interfaces to different access networks (distinct foreign
links or distinct home links, or a combination of both)
o If several interfaces are activated and configured with valid
addresses, the MN should be able to share its traffic load among
these interfaces.
o If an interface is used as backup and the primary interface failed
(loss of connection), a mechanism should be available to quickly
activate the backup interface and redirect traffic.
Montavont, et al. Expires July 11, 2005 [Page 6]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005
o The MN must be able to use multiple Home Agents simultaneously if
they are available
o When considering the goals/benefits defined in [3], 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. In order to achieve transparency, a necessary (may or
may not be sufficient) condition is for the end-point addresses to
remain unchanged. This is in-view of the large amount of Internet
traffic today are carried by TCP, which unlike SCTP, cannot handle
multiple end-point address pairs.
We will next analyse issues arising from current Mobile IPv6
Specifications when trying to fulfill these requirements.
5. Scenarios
This section is split into two parts according to the number of
interfaces on the mobile node. This distinction is made to help the
reader to better understand the different cases, but also because the
benefits for the mobile node will be different according to this
parameter.
1. (1,1,1): 1 iface, 1 HoA, 1 CoA
The node is not multihomed. The node has only one interface,
with one HoA and is currently away from its home link (one CoA on
the foreign link).
Achievable benefits: none.
2. (1,n,1): 1 iface, several HoAs, 1 CoA
The node is multihomed, since it has several HoAs. This case may
happen when a node is getting access to Internet through
different ISPs and each offers a Mobile IPv6 service to the node.
That way, the node will have a HoA per ISP. Once the node is
connected to a visited IPv6 subnet, it gets one CoA. This CoA
may be registered with all the Home Agents provided by the ISPs,
in order to remain simulteneously reachable through all its HoAs.
Achievable benefits: fault recovery, load sharing, preference
settings.
3. (1,1,n): 1 iface, 1 HoA, several CoAs
The node is multihomed since it has several CoAs. This case may
Montavont, et al. Expires July 11, 2005 [Page 7]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005
occur when the interface of the node is connected to a link where
multiple IPv6 prefixes are advertised.
Achievable benefits: fault recovery, load sharing, bicasting,
preference settings.
4. (1,n,n): 1 iface, several HoAs, several CoAs
The node is multihomed, since it has multiple addresses. This
case can be viewed as a combination of the two cases described
above: the node has several HoAs (e.g. given by different ISPs)
and several CoAs (e.g. because the node is receiving multiple
IPv6 prefixes).
Achievable benefits: fault recovery, load sharing, bicasting,
preferences settings.
5. (n,1,1): n ifaces, 1 HoA, 1 CoA
The node is multihomed: this is a special case of a node with two
interfaces connected to different IPv6 subnets; one of the subnet
is the home network of the node and allows the node to directly
use its HoA (without the MIPv6 mechanisms). The node can build a
temporarily IPv6 address on its other interface but it cannot
register the temporary address with its Home Agent because the
node is using its HoA. If the node decides to update its
location, it will not be able to use its HoA on the interface
connected to its home link.
Achievable benefits: ubiquitous access, fault recovery, load
sharing, load balancing, preference settings
6. (n,1,n): n ifaces, 1 HoA, several CoAs
The node is multihomed: the node has several addresses to choose
from. For example, consider a node with several interfaces, each
connected to an IPv6 network (the same or not). In this example,
at least one global IPv6 address is configured on each interface.
The node has only one home link, and only one Home Agent.
Achievable benefits: ubiquitous access, fault recovery, load
sharing, load balancing, bicasting, preference settings
7. (n,n,1): n ifaces, several HoA, one CoA
The node is multihomed. This case extends the case (n,1,1) when
the node has several HoAs, for example from multiple ISPs. The
CoA can be associated with each HoA.
Montavont, et al. Expires July 11, 2005 [Page 8]
Achievable benefits: ubiquitous access, fault recovery, load
sharing, load balancing, bicasting, preference settings
8. (n,n,n): n ifaces, several HoAs, several CoAs
The node is multihomed. Many scenarios may lead to this case.
For example, 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
advertised.
Achievable benefits: ubiquitous access, fault recovery, load
sharing, load balancing, bicasting, preference settings
6. Problem Statement
Internet connectivity is guaranteed for a MN as long as at least one
path is maintained between the MN and the fixed Internet. When an
alternative path must be found to substitute a failed one, the loss
of the previous path may result in broken sessions. New transport
sessions would have to be established over the alternate path if no
mechanism is provided to make this change transparent at layers above
layer 3.
In order to meet other expected benefits of multihoming, multiple
paths may be maintained simulateneously (e.g. for load balancing,
load sharing) or not (e.g. for redundancy) between the mobile node
and the home network(s). 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 fault
recovery, preferences) or to split traffic between multiple paths
(e.g. for load sharing, load balacing)
Existing protocols may not be able to handle such cases. 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 MIP6 solely, whereas other issues are not at all
related to MIP6. However, such non MIP6 issues must be solved in
order to reach all the goals of multihoming.
6.1 Deciding which HoA a new CoA should be bound to
In the (*,n,*) cases, the MN has multiple HoAs. When the MN moves
and configure a new CoA, the newly obtained CoA must be bound to a
specific HoA. The current MIP6 specification doesn't provide a
mechanism to determine to which HoA this newly acquirred CoA should
be bound to.
With no such mechanism, the MN may be confused and may bind this CoA
Montavont, et al. Expires July 11, 2005 [Page 9]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005
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.2 Binding Multiple CoAs to a HoA
In the (*,1,n) cases, multiple CoAs would be available on the MN.
However, the current MIP6 specification doesn't allow to register
multiple CoAs for a single HoA.
6.3 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 disctinct
home links. MN is connected to these two home links via two
interfaces. If the MN looses its connectivity on its first
interface, HoA1 is not reachable. It may then want to register HoA2
as a CoA for HoA1 in order to keep receiving packets intended to
HoA1, via the second interface.
According to the definition of a CoA, the current MIP6 specification
prohibits to register another HoA as a CoA. In order to counter
this, a MN must be able to register whatever address it owns with any
of its HoA. A mechanism is needed to determine how to decide which
HoA will be chosen and the definition of a HoA and CoA might be
extended.
6.4 Using multiple interfaces simultanouely
In (n,*,*) cases, the MN has multiple interfaces. The simultaneous
use of several interfaces would allow a mobile node to spread its
different flows between its interfaces. MIP6 does not presently
allow the MN to register and use several interfaces simultaneously,
regardless the number of HoAs and CoAs the mobile node may have and
regardless the network topology the mobile node is connected to.
6.5 Relationship between interfaces and HoAs
In (*,n,*) cases, MIPv6 does not define any relation between HoAs and
interfaces, and particularly there is no mechanism to bind HoAs to
interfaces. For example, consider a MN equipped with two HoAs and
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.
Montavont, et al. Expires July 11, 2005 [Page 10]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005
HoA1 HoA2
CoA 1 CoA2 CoA3
Iface1 Iface2 Iface3
Figure 2: Illustration of the case (3,2,3)
HoA must always be assigned to an activated interface and if the MN
is connected to its home link, the corresponding HoA must be used on
this interface. In some cases, the HoA then would have to be
re-assigned to another interface in case of connection loss or
attachment to the home link.
6.6 Flow redirection
In the (n,*,*) cases, the MN has multiple interfaces. If one
interface fails, established sessions on the failed interface would
break if no support mechanism is used to redirect flows from the
failed interface to another.
MIP6 allows a MN to move transparently from one access link to
another access link when the same interface is used, i.e. in cases
(1,*,*). However, in cases (n,*,*), MIP6 doesn't provide a mechanism
to transmit traffic established over one interface to another
interface.
Movement detection might be extended to include other triggers such
as the loss of connectivity on one interface. Moreover, the chosen
mechanism must work whatever the previous bindings the MN has
registered. The redirection between interfaces can be performed
transparently to the MNs if mechanisms such as specified in [5] are
brought to the MN.
6.7 Flows filtering
In the (n,*,*) case, the node has multiple interfaces. If each
interface may be used differently according to some 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.
In order to optimize the global connectivity of a multihomed node, a
specific mechanims may allow a multihomed node to set filters on
flows on distant nodes (Correspondent Node or Home Agent), such as
mechanisms proposed by [6], [7] and [8].
Montavont, et al. Expires July 11, 2005 [Page 11]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005
6.8 Multiple HoAs
In the (n,*,*) cases listed in Section 5, the node may have one of
its interfaces directly connected to a home link. This may have an
impact on the multihoming management.
For example, if we consider the case (n,n,n) with a node having three
interfaces, three HoAs and two CoAs (connected to two visited IPv6
subnets), the CoAs cannot be registered with the Home Agent serving
the node on the home link it is connected to.
Otherwise, the case (n,n,n) can translate into either case (n,n,1) or
(n,n,0) according to the way the node is connected to the Internet.
Case (n,n,1) only happens when the node is connected to a visited
link with only one interface and obtain only one CoA. Other
interfaces are connected to the home link(s). In the case (n,n,0),
i.e. several interfaces, several HoAs, and no CoA, all interfaces of
the node are connected to their respective home links.
7. Conclusion
In this document, we have raised issues related to multihoming. Even
if MIPv6 can be used as mechanism to manage multihomed MN, triggers
of flows redirection between interfaces/addresses are not adapted to
the multihoming status of the node. Also, we have shown that in some
scenarios MIPv6 is ambigous in the CoA / HoA definition and in the
mapping between HoAs, CoAs and CoAs. Finaly, we have also raised
issues not directly related to MIPv6, but which are needed to achieve
benefits described in [3].
8. Contributors
The following people have contributed ideas, text and comments to
this draft: Koojana Kuladinithi, Eun Kyoung Paik.
9. Acknowledgments
The authors would like to than all the people who have sent comments
so far, particularly Tobias Kufner for raising new issues.
10 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
Montavont, et al. Expires July 11, 2005 [Page 12]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005
Agents", RFC 3776, June 2004.
[3] Ernst, T., "Goals and Benefits of Multihoming",
draft-multihoming-generic-goals-and-benefits-00 (work in
progress), February 2004.
[4] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
3753, June 2004.
[5] Montavont, N., Noel, T. and M. Kassi-Lahlou, "MIPv6 for
Multiple Interfaces", draft-montavont-mobileip-mmi-00 (work in
progress), July 2002.
[6] Soliman, H., Malki, K. and C. Castelluccia, "Per-flow movement
in MIPv6", draft-soliman-mobileip-flow-move-02 (work in
progress), July 2002.
[7] Montavont, N. and T. Noel, "Home Agent Filtering for Mobile
IPv6", draft-montavont-mobileip-ha-filtering-v6-00 (work in
progress), January 2004.
[8] Kuladinithi, K., "Filters for Mobile IPv6 Bindings (NOMADv6)",
draft-nomadv6-mobileip-filters-02 (work in progress), June
2004.
[9] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-02 (work in progress), October
2004.
[10] Wakikawa, R., "Multiple Care-of Addresses Registration",
draft-wakikawa-mobileip-multiplecoa-03 (work in progress), July
2004.
[11] Stemm, M. and R. Katz, "Vertical Handoffs in Wireless Overlay
Networks", Journal Mobile Networks and Applications, vol. 3,
number 4, pages 335-350, 1998.
Montavont, et al. Expires July 11, 2005 [Page 13]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005
Authors' Addresses
Nicolas Montavont
LSIIT - Univerity Louis Pasteur
Pole API, bureau C444
Boulevard Sebastien Brant
Illkirch 67400
FRANCE
Phone: (33) 3 90 24 45 87
EMail: montavont@dpt-info.u-strasbg.fr
URI: http://www-r2.u-strasbg.fr/~montavont/
Ryuji Wakikawa
Keio University
Jun Murai Lab., 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.mobileip.jp/
Thierry Ernst
WIDE at Keio University
Jun Murai Lab., Keio University.
K-square Town Campus, 1488-8 Ogura, Saiwa-Ku
Kawasaki, Kanagawa 212-0054
Japan
Phone: +81-44-580-1600
Fax: +81-44-580-1437
EMail: ernst@sfc.wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~ernst/
Montavont, et al. Expires July 11, 2005 [Page 14]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005
Thomas Noel
LSIIT - Univerity Louis Pasteur
Pole API, bureau C444
Boulevard Sebastien Brant
Illkirch 67400
FRANCE
Phone: (33) 3 90 24 45 92
EMail: noel@dpt-info.u-strasbg.fr
URI: http://www-r2.u-strasbg.fr/~noel/
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: cwng@psl.com.sg
Montavont, et al. Expires July 11, 2005 [Page 15]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Montavont, et al. Expires July 11, 2005 [Page 16]