draft-ietf-nemo-multihoming-issues-02.txt   draft-ietf-nemo-multihoming-issues-03.txt 
NEMO Working Group C. Ng NEMO Working Group C. Ng
Internet-Draft Panasonic Singapore Labs Internet-Draft Panasonic Singapore Labs
Expires: August 25, 2005 E. Paik Expires: January 19, 2006 E. Paik
KT KT
T. Ernst T. Ernst
WIDE at Keio University WIDE at Keio University
February 21, 2005 M. Bagnulo
UC3M
July 18, 2005
Analysis of Multihoming in Network Mobility Support Analysis of Multihoming in Network Mobility Support
draft-ietf-nemo-multihoming-issues-02 draft-ietf-nemo-multihoming-issues-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 25, 2005. This Internet-Draft will expire on January 19, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document is an analysis of multihoming in the context of network This document is an analysis of multihoming in the context of network
mobility (NEMO). As there are many situations in which mobile mobility (NEMO) in IPv6. As there are many situations in which
networks may be multihomed, a taxonomy is proposed to classify the mobile networks may be multihomed, a taxonomy is proposed to classify
possible configurations. We also describe possible deployment the possible configurations. The possible deployment scenarios of
scenarios and we attempt to identify issues that arise when mobile multihomed mobile networks are described together with the associated
networks are multihomed while mobility supports is taken care by NEMO issues when network mobility is supported by RFC 3963 (NEMO Basic
Basic Support. Support). Issues are classified according to the Working Group which
is the best chartered to solve them.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Classification . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Classification . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 (1,1,1): Single MR, Single HA, Single MNP . . . . . . . . 7 2.1 (1,1,1): Single MR, Single HA, Single MNP . . . . . . . . 7
2.2 (1,1,n): Single MR, Single HA, Multiple MNPs . . . . . . . 7 2.2 (1,1,n): Single MR, Single HA, Multiple MNPs . . . . . . . 7
2.3 (1,n,1): Single MR, Multiple HAs, Single MNP . . . . . . . 8 2.3 (1,n,1): Single MR, Multiple HAs, Single MNP . . . . . . . 8
2.4 (1,n,n): Single MR, Multiple HAs, Multiple MNPs . . . . . 8 2.4 (1,n,n): Single MR, Multiple HAs, Multiple MNPs . . . . . 9
2.5 (n,1,1): Multiple MRs, Single HA, Single MNP . . . . . . . 9 2.5 (n,1,1): Multiple MRs, Single HA, Single MNP . . . . . . . 9
2.6 (n,1,n): Multiple MRs, Single HA, Multiple MNPs . . . . . 9 2.6 (n,1,n): Multiple MRs, Single HA, Multiple MNPs . . . . . 10
2.7 (n,n,1): Multiple MRs, Multiple HAs, Single MNP . . . . . 10 2.7 (n,n,1): Multiple MRs, Multiple HAs, Single MNP . . . . . 10
2.8 (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs . . . . 10 2.8 (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs . . . . 11
3. Deployment Scenarios and Prerequisites . . . . . . . . . . . . 12 3. Deployment Scenarios and Prerequisites . . . . . . . . . . . . 13
3.1 Deployment Scenarios . . . . . . . . . . . . . . . . . . . 12 3.1 Deployment Scenarios . . . . . . . . . . . . . . . . . . . 13
3.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . 13 3.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . 14
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 15 4. Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 16
4.1 Path Survival . . . . . . . . . . . . . . . . . . . . . . 15 4.1 Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 16
4.2 Path Selection . . . . . . . . . . . . . . . . . . . . . . 15 4.1.1 Failure Detection . . . . . . . . . . . . . . . . . . 16
4.3 Ingress Filtering . . . . . . . . . . . . . . . . . . . . 16 4.1.2 Path Exploration . . . . . . . . . . . . . . . . . . . 18
4.4 Failure Detection . . . . . . . . . . . . . . . . . . . . 18 4.1.3 Path Selection . . . . . . . . . . . . . . . . . . . . 19
4.5 Media Detection . . . . . . . . . . . . . . . . . . . . . 19 4.1.4 Re-Homing . . . . . . . . . . . . . . . . . . . . . . 20
4.6 HA Synchronization . . . . . . . . . . . . . . . . . . . . 20 4.2 Ingress Filtering . . . . . . . . . . . . . . . . . . . . 21
4.7 MR Synchronization . . . . . . . . . . . . . . . . . . . . 20 4.3 Media Detection . . . . . . . . . . . . . . . . . . . . . 22
4.8 Prefix Delegation . . . . . . . . . . . . . . . . . . . . 21 4.4 HA Synchronization . . . . . . . . . . . . . . . . . . . . 23
4.9 Multiple Bindings/Registrations . . . . . . . . . . . . . 21 4.5 MR Synchronization . . . . . . . . . . . . . . . . . . . . 23
4.10 Source Address Selection . . . . . . . . . . . . . . . . . 21 4.6 Prefix Delegation . . . . . . . . . . . . . . . . . . . . 24
4.11 Impact on the Routing Infrastructure . . . . . . . . . . . 22 4.7 Multiple Bindings/Registrations . . . . . . . . . . . . . 24
4.12 Nested Mobile Networks . . . . . . . . . . . . . . . . . . 22 4.8 Source Address Selection . . . . . . . . . . . . . . . . . 24
4.13 Split Mobile Networks . . . . . . . . . . . . . . . . . . 22 4.9 Loop Prevention in Nested Mobile Networks . . . . . . . . 25
4.10 Prefix Ownership . . . . . . . . . . . . . . . . . . . . . 25
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5. Matrix [Issues,(x,y,z) Configuration] . . . . . . . . . . . . 26
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
A. Alternative Classifications Approach . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.1 Ownership-Oriented Approach . . . . . . . . . . . . . . . 27 10.1 Normative References . . . . . . . . . . . . . . . . . . . 28
A.1.1 ISP Model . . . . . . . . . . . . . . . . . . . . . . 27 10.2 Informative References . . . . . . . . . . . . . . . . . . 28
A.1.2 Subscriber/Provider Model . . . . . . . . . . . . . . 28
A.2 Problem-Oriented Approach . . . . . . . . . . . . . . . . 30
B. Nested Tunneling for Fault Tolerance . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
B.1 Detecting Presence of Alternate Routes . . . . . . . . . . 31
B.2 Re-Establishment of Bi-Directional Tunnels . . . . . . . . 31
B.2.1 Using Alternate Egress Interface . . . . . . . . . . . 32
B.2.2 Using Alternate Mobile Router . . . . . . . . . . . . 32
B.3 To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . 33
C. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 34 A. Alternative Classifications Approach . . . . . . . . . . . . . 32
A.1 Ownership-Oriented Approach . . . . . . . . . . . . . . . 32
A.1.1 ISP Model . . . . . . . . . . . . . . . . . . . . . . 32
A.1.2 Subscriber/Provider Model . . . . . . . . . . . . . . 33
A.2 Problem-Oriented Approach . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . 36 B. Nested Tunneling for Fault Tolerance . . . . . . . . . . . . . 36
B.1 Detecting Presence of Alternate Routes . . . . . . . . . . 36
B.2 Re-Establishment of Bi-Directional Tunnels . . . . . . . . 36
B.2.1 Using Alternate Egress Interface . . . . . . . . . . . 37
B.2.2 Using Alternate Mobile Router . . . . . . . . . . . . 37
B.3 To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . 38
C. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . . 41
1. Introduction 1. Introduction
The design goals and objectives of Network Mobility Support (NEMO) The design goals and objectives of Network Mobility Support (NEMO) in
are identified in [1] while the terminology is being described in [2] IPv6 are identified in [1] while the terminology is being described
and [3]. NEMO Basic Support [4] is the solution proposed by the NEMO in [2] and [3]. NEMO Basic Support (RFC 3963) [4] is the solution
Working Group to provide continuous Internet connectivity to nodes proposed by the NEMO Working Group to provide continuous Internet
located in a mobile network. This solutions basically solves the connectivity to nodes located in an IPv6 mobile network, e.g. like in
problem by setting up bi-directional tunnels between the mobile an in-vehicle embedded IP network. The NEMO Basic Support solution
routers (MRs) connecting the mobile network to the Internet and their basically solves the problem by setting up bi-directional tunnels
respective Home Agents (HAs), much how this is done in Mobile IPv6 between the mobile routers (MRs) connecting the mobile network to the
[5], the solution for host mobility. NEMO Basic Support is Internet and their respective Home Agents (HAs), much how this is
transparent to nodes located behind the mobile router (i.e. the done in Mobile IPv6 [5], the solution for host mobility support.
mobile network nodes, or MNNs) and as such doesn't require MNNs to NEMO Basic Support is transparent to nodes located behind the mobile
take any action in the mobility management. router (i.e. the mobile network nodes, or MNNs) and as such doesn't
require MNNs to take any action in the mobility management.
However, mobile networks are typically connected by means of wireless However, mobile networks are typically connected by means of wireless
and thus less reliable links; there could also be many nodes behind and thus less reliable links; there could also be many nodes behind
the MR. A loss of connectivity or a failure to connect to the the MR. A loss of connectivity or a failure to connect to the
Internet has thus a more significant impact than for a single node. Internet has thus a more significant impact than for a single mobile
Real-life scenarios as illustrated in [6] demonstrate that providing node. Scenarios illustrated in [6] demonstrate that providing a
a permanent access to mobile networks such as vehicles typically permanent access to mobile networks such as vehicles typically
require the use of several interfaces and technologies since the require the use of several interfaces and technologies since the
mobile network may be moving in distant geographical locations where mobile network may be moving in distant geographical locations where
different access technologies are provided and governed by distinct different access technologies are provided and governed by distinct
access control policies. access control policies.
As specified by R.12 in section 5 of [1], the NEMO WG must ensure As specified by R.12 in section 5 of [1], the NEMO WG must ensure
that NEMO Basic Support does not prevent mobile networks to be that NEMO Basic Support does not prevent mobile networks to be
multihomed, i.e. when there is more than one point of attachment multihomed, i.e. when there is more than one point of attachment
between the mobile network and the Internet (see definitions in between the mobile network and the Internet (see definitions in [3]).
[3]).. This arises either when a MR has multiple egress interfaces. This arises either:
Using NEMO Basic Support, this translates into having multiple
bi-directional tunnels between the mobile network and its HA(s), and o when a MR has multiple egress interfaces, or
may result into multiple MNPs being advertised to the MNNs. However,
o the mobile network has multiple MRs, or
o the mobile network is associated with multiple HAs, or
o multiple global prefixes are available in the mobile network.
Using NEMO Basic Support, this would translate into having multiple
bi-directional tunnels between the MR(s) and the corresponding HA,
and may result into multiple MNPs available to the MNNs. However,
NEMO Basic Support does not specify any particular mechanism to NEMO Basic Support does not specify any particular mechanism to
manage multiple bi-directional tunnels. The objective of this memo manage multiple bi-directional tunnels. The objective of this memo
is thus three-folds: is thus multi-folded:
o to identify which multihoming configurations are useful, o to determine all the potential multihomed configurations for a
NEMO, and then to identify which of those may be useful in a real
life scenario,
o to identify issues that may prevent useful multihomed o to capture issues that may prevent some multihomed configurations
configurations to be supported under the operation of NEMO Basic to be supported under the operation of NEMO Basic Support. It
Support. It doesn't mean that those not supported will not work doesn't necessarily mean that those not supported will not work
with NEMO Basic Support, just that it is up to the implementors to with NEMO Basic Support, as it may be up to the implementors to
make it work (hopefully issues discussed in this memo will be make it work (hopefully this memo will be helpful to these
helpful to these implementors). implementors).
For doing so, a taxonomy to classify the possible multihomed o to identify potential solutions to the previously identified
configurations is described in Section 2. Deployment scenarios, issues.
their benefits, and requirements to meet these benefits are
illustrated in Section 3. Following this, we study the general
issues in Section 4, and we conclude with an evaluation of NEMO Basic
Support for multihomed configurations. Alternative classifications
are outlined in the Appendix.
In order to understand this memo, the reader is expected to be o to decide which issues are worth to be solved, and to determine
familiar with the above cited documents, i.e. with the NEMO which WG should address each of the issues that are worth solving.
terminology as defined in [2] (section 3) and [3], Goals and Benefits
of Multihoming [6], Goals and Requirements of Network Mobility
Support [1], and the NEMO Basic Support specification [4]. Goals and
benefits for multihoming as discussed in [6] are applicable to fixed
nodes, mobile nodes, fixed networks and mobile networks.
This document considers multihoming only from the IPv6 point of view. In order to reach these objectives, a taxonomy to classify the
possible multihomed configurations is described in Section 2.
Deployment scenarios, their benefits, and requirements to meet these
benefits are illustrated in Section 3. Following this, the related
issues are studied in Section 4. The issues are then summarized in a
matrix for each of the deployment scenario (Section 5). This memo
concludes with an evaluation of NEMO Basic Support for multihomed
configurations. Alternative classifications are outlined in the
Appendix.
The readers should note that this document considers multihoming only
from the point of view of an IPv6 environment. In order to
understand this memo, the reader is expected to be familiar with the
above cited documents, i.e. with the NEMO terminology as defined in
[2] (section 3) and [3], Goals and Benefits of Multihoming [6], Goals
and Requirements of Network Mobility Support [1], and the NEMO Basic
Support specification [4]. Goals and benefits of multihoming as
discussed in [6] are applicable to fixed nodes, mobile nodes, fixed
networks and mobile networks.
2. Classification 2. Classification
Various discussions on the topic of multihoming issues in NEMO have As there are several configurations in which mobile networks are
been carried out on the mailing list and at IETF meetings. As there multihomed, there is a need to classify them into a clearly defined
are several configurations in which mobile networks are multihomed, taxonomy. This can be done in various ways. A Configuration-
there is a need to classify them into a clearly defined taxonomy. Oriented taxonomy is described in this section. Two other
This can be done in various ways. Three approaches have been taxonomies, namely, the Ownership-Oriented Approach, and the Problem-
proposed on the NEMO mailing list. These are, namely, (i) the Oriented Approach are outlined in Appendix A.1 and Appendix A.2.
Configuration-Oriented Approach, (ii) the Ownership-Oriented
Approach, and (iii) the Problem-Oriented Approach. As the WG
consensus seems to have converged to the Configuration-Oriented
Approach, we only describe this approach here. The other two
approaches are outlined in Appendix A.1 and Appendix A.2.
Multihomed configurations can be classified depending on how many Multihomed configurations can be classified depending on how many
mobile routers are present, how many egress interfaces, Care-of mobile routers are present, how many egress interfaces, Care-of
Address (CoA) and Home Addresses (HoA) the mobile routers have, how Address (CoA) and Home Addresses (HoA) the mobile routers have, how
many prefixes (MNPs) are advertised to the mobile network nodes, etc. many prefixes (MNPs) are available to the mobile network nodes, etc.
For doing so, we use three key parameters differentiating different We use three key parameters to differentiate the multihomed
multihomed configurations. With these parameters, we can refer to configurations. Using these parameters, each configuration is
each configuration by the 3-tuple (x,y,z), where 'x', 'y', 'z' are referred by the 3-tuple (x,y,z), where 'x', 'y', 'z' are defined as
defined as follows: follows:
o 'x' indicates the number of MRs where: o 'x' indicates the number of MRs where:
x=1 implies a mobile network has only a single MR, presumably x=1 implies a mobile network has only a single MR, presumably
multihomed. multihomed.
x=N implies a mobile network has more than one MR. x=n implies a mobile network has more than one MR.
o 'y' indicates the number of HAs associated with the entire mobile o 'y' indicates the number of HAs associated with the entire mobile
network, where: network, where:
y=1 implies that a single HA is assigned to the mobile network. y=1 implies that a single HA is assigned to the mobile network.
y=N implies that multiple HAs (possibly in different y=n implies that multiple HAs are assigned to the mobile network.
administrative domains) are assigned to the mobile network.
o 'z' indicates the number of MNPs announced to MNNs, where: o 'z' indicates the number of MNPs available within the NEMO, where:
z=1 implies that a single MNP is advertised to the MNNs. z=1 implies that a single MNP is available in the NEMO.
z=N implies that multiple MNPs are advertised to the MNNs. z=N implies that multiple MNPs are available in the NEMO
It can be seen that the above three parameters are fairly orthogonal It can be seen that the above three parameters are fairly orthogonal
to one another. Thus different values of 'x', 'y' and 'z' give rise to one another. Thus different values of 'x', 'y' and 'z' give rise
to different combinations of the 3-tuple (x,y,z). As described in to different combinations of the 3-tuple (x,y,z).
the sub-sections below, a total of 8 possible configurations can be
identified.
One thing the reader has to keep in mind is that in each of the
following 8 cases, the MR may be multihomed if either (i) multiple
prefixes are advertised (on the home link, or on the visited link),
or (ii) the MR is equipped with multiple interfaces. In such a case,
the MR would have a combination of Home Address / Care-of Address
pairs. Issues pertaining to a multihomed MR are also addressed in
the companion document [7].
A simplified analysis of multihoming configuration in NEMO Basic As described in the sub-sections below, a total of 8 possible
Support using the same classification can be found in [8]. configurations can be identified. One thing the reader has to keep
in mind is that in each of the following 8 cases, the MR may be
multihomed if either (i) multiple prefixes are available (on the home
link, or on the visited link), or (ii) the MR is equipped with
multiple interfaces. In such a case, the MR would have multiple Home
Address / Care-of Address pairs. Issues pertaining to a multihomed
MR are also addressed in [7]. In addition, the readers should also
keep in mind that when "MNP(s) is/are available in the NEMO", the
MNP(s) may either be explicitly announced by the MR via router
advertisement, or mad available through Dynamic Host Configuration
Protocol (DHCP).
2.1 (1,1,1): Single MR, Single HA, Single MNP 2.1 (1,1,1): Single MR, Single HA, Single MNP
The (1,1,1) mobile network has only one MR advertising a single MNP. The (1,1,1) mobile network has only one MR, it is associated with a
In addition, the MR is associated with only one HA at any one time. single HA, and a single MNP is available in the NEMO. To fall into a
A bi-directional tunnel may be established between each pair of Home multihomed configuration, at least one of the following conditions
Address / Care-of address if the MR is itself multihomed. must hold:
The MR may be multihomed and MNNs are (usually) not multihomed since o The MR has multiple interfaces, or
they would configure a single address on the single MNP announced on
o Multiple global prefixes are available on the visited link, or
o Multiple global prefixes are available on the home link (Note that
in this case, those prefixes are not all available in the NEMO,
since there is only a single MNP in the NEMO)
A bi-directional tunnel would then be established between each pair
of Home Address / Care-of Address.
Regarding MNNs, they are (usually) not multihomed since they would
configure a single global address from the single MNP available on
the link they are attached to. the link they are attached to.
_____ _____
_ p _ | | _ p _ | |
|_|-|<-_ |-|_|-| |-| _ |_|-|<-_ |-|_|-| |-| _
_ |-|_|=| |_____| | _ |-|_| _ |-|_|=| |_____| | _ |-|_|
|_|-| | |-|_|-| |_|-| | |-|_|-|
| |
MNNs MR AR Internet AR HA MNNs MR AR Internet AR HA
Figure 1: (1,1,1): 1 MR, 1 HA, 1 MNP Figure 1: (1,1,1): 1 MR, 1 HA, 1 MNP
2.2 (1,1,n): Single MR, Single HA, Multiple MNPs 2.2 (1,1,n): Single MR, Single HA, Multiple MNPs
The (1,1,n) mobile network has only one MR, which is associated to The (1,1,n) mobile network has only one MR, it is associated with a
only one HA at any one time. However, two or more MNPs are single HA and two or more MNPs are available in the NEMO.
advertised to the mobile network nodes.
The MR may be itself multihomed, and MNNs are multihomed if several The MR may be itself multihomed, as detailed in Section 2.1. In such
MNPs are advertised on the link they are attached to. If that a case, a bi-directional tunnel would be established between each
conditions holds, MNNs would configure an address with each MNP pair of Home Address / Care-of Address.
announced on the link.
Regarding MNNs, they are multihomed because several MNPs are
available on the link they are attached to. The MNNs would then
configure a global address with each MNP available on the link.
_____ _____
_ p1,p2 _ | | _ p1,p2 _ | |
|_|-|<-_ |-|_|-| |-| _ |_|-|<-_ |-|_|-| |-| _
_ |-|_|=| |_____| | _ |-|_| _ |-|_|=| |_____| | _ |-|_|
|_|-| | |-|_|-| |_|-| | |-|_|-|
| |
MNNs MR AR Internet AR HA MNNs MR AR Internet AR HA
Figure 2: (1,1,n): 1 MR, 1 HA, multiple MNPs Figure 2: (1,1,n): 1 MR, 1 HA, multiple MNPs
2.3 (1,n,1): Single MR, Multiple HAs, Single MNP 2.3 (1,n,1): Single MR, Multiple HAs, Single MNP
The (1,n,1) mobile network has only one MR advertising a single MNP. The (1,n,1) mobile network has only one MR and a single MNP is
The MR, however, is associated to multiple HAs, possibly one HA per available in the NEMO. The MR, however, is associated with multiple
Home Address, or one HA per egress interface. HAs, possibly one HA per Home Address, or one HA per egress
interface.
The MR may be multihomed whereas MNNs are (usually) not multihomed The NEMO is multihomed since it has multiple HAs, but in addition the
since they would configure a single address on the single MNP conditions detailed in Section 2.1 may also hold for the MR. A bi-
announced on the link they are attached to. directional tunnel would then be established between each pair of
Home Address / Care-of Address.
Regarding MNNs, they are (usually) not multihomed since they would
configure a single global address from the single MNP available on
the link they are attached to.
AR HA2 AR HA2
_ | _ |
|-|_|-| _ |-|_|-| _
_____ | |-|_| _____ | |-|_|
_ p _ | |-| _ p _ | |-|
|_|-|<-_ |-|_|-| | |_|-|<-_ |-|_|-| |
_ |-|_|=| |_____|-| _ _ |-|_|=| |_____|-| _
|_|-| | | _ |-|_| |_|-| | | _ |-|_|
|-|_|-| |-|_|-|
| |
MNNs MR AR Internet AR HA1 MNNs MR AR Internet AR HA1
Figure 3: (1,n,1): 1 MR, multiple HAs, 1 MNP Figure 3: (1,n,1): 1 MR, multiple HAs, 1 MNP
2.4 (1,n,n): Single MR, Multiple HAs, Multiple MNPs 2.4 (1,n,n): Single MR, Multiple HAs, Multiple MNPs
The (1,n,n) mobile network has only one MR. However, the MR is The (1,n,n) mobile network has only one MR. However, the MR is
associated with multiple HAs, possibly one per Home Address (or one associated with multiple HAs, possibly one per Home Address (or one
HA per egress interface), and the MR advertises more than one MNP on HA per egress interface), and more than one MNP is available in the
its ingress interfaces. No assumption is made on whether or not the NEMO.
HAs belongs to the same administrative domain.
The MR may be multihomed, and the MNNs are generally multihomed since The MR is multihomed since it has multiple HAs, but in addition the
they would configure an address on each MNP announced on the link conditions detailed in Section 2.1 may also hold. A bi-directional
they are attached to. tunnel would then be established between each pair of Home Address /
Care-of Address.
Regarding MNNs, they are generally multihomed since they would
configure a global address from each MNP available on the link they
are attached to.
AR HA2 AR HA2
_ | _ _ | _
_____ |-|_|-|-|_| _____ |-|_|-|-|_|
_ p1,p2 _ | |-| | _ p1,p2 _ | |-| |
|_|-|<-_ |-|_|-| | _ |_|-|<-_ |-|_|-| | _
_ |-|_|=| |_____|-| _ |-|_| _ |-|_|=| |_____|-| _ |-|_|
|_|-| | |-|_|-| |_|-| | |-|_|-|
| | | |
MNNs MR AR Internet AR HA1 MNNs MR AR Internet AR HA1
Figure 4: (1,n,n): 1 MR, multiple HAs, multiple MNPs Figure 4: (1,n,n): 1 MR, multiple HAs, multiple MNPs
2.5 (n,1,1): Multiple MRs, Single HA, Single MNP 2.5 (n,1,1): Multiple MRs, Single HA, Single MNP
The (n,1,1) mobile network has more than one MR advertising global The (n,1,1) mobile network has more than one MR advertising global
routes. These MRs, however, advertise the same MNP and are routes. However, the MR(s) are associated with as single HA, and
associated with the same HA. there in a single MNP available in the NEMO.
Each MR may be itself multihomed, whereas MNNs are (usually) not The NEMO is multihomed since it has multiple MRs, but in addition the
multihomed since they would configure a single address on the single conditions detailed in Section 2.1 may also hold for each MR. A bi-
MNP announced on the link they are attached to. directional tunnel would then be established between each pair of
Home Address / Care-of Address.
Regarding MNNs, they are (usually) not multihomed since they would
configure a single global address from the single MNP available on
the link they are attached to.
MR2 MR2
p<-_ | p<-_ |
_ |-|_|-| _____ _ |-|_|-| _____
|_|-| |-| | |_|-| |-| |
_ | | |-| _ _ | | |-| _
|_|-| _ |-|_____| | _ |-|_| |_|-| _ |-|_____| | _ |-|_|
|-|_|-| |-|_|-| |-|_|-| |-|_|-|
p<- | | p<- | |
MNNs MR1 Internet AR HA MNNs MR1 Internet AR HA
Figure 5: (n,1,1): Multiple MRs, 1 HA, 1 MNP Figure 5: (n,1,1): Multiple MRs, 1 HA, 1 MNP
2.6 (n,1,n): Multiple MRs, Single HA, Multiple MNPs 2.6 (n,1,n): Multiple MRs, Single HA, Multiple MNPs
The (n,1,n) mobile network has more than one MR; multiple global The (n,1,n) mobile network has more than one MR; multiple global
routes and different MNPs are advertised by the MRs. routes are advertised by the MRs and multiple MNPs are available
within the NEMO.
Each MR may be itself multihomed, and MNNs are generally multihomed The NEMO is multihomed since it has multiple MRs, but in addition the
since they would configure an address on each MNP announced on the conditions detailed in Section 2.1 may also hold for each MR. A bi-
link they are attached to. directional tunnel would then be established between each pair of
Home Address / Care-of Address.
Regarding MNNs, they are generally multihomed since they would
configure a global address from each MNP available on the link they
are attached to.
MR2 MR2
p2<-_ | p2<-_ |
_ |-|_|-| _____ _ |-|_|-| _____
|_|-| |-| | |_|-| |-| |
_ | | |-| _ _ | | |-| _
|_|-| _ |-|_____| | _ |-|_| |_|-| _ |-|_____| | _ |-|_|
|-|_|-| |-|_|-| |-|_|-| |-|_|-|
p1<- | | p1<- | |
MNNs MR1 Internet AR HA MNNs MR1 Internet AR HA
Figure 6: (n,1,n): Multiple MRs, 1 HA, multiple MNPs Figure 6: (n,1,n): Multiple MRs, 1 HA, multiple MNPs
2.7 (n,n,1): Multiple MRs, Multiple HAs, Single MNP 2.7 (n,n,1): Multiple MRs, Multiple HAs, Single MNP
The (n,n,1) mobile network has more than one MR advertising multiple The (n,n,1) mobile network has more than one MR advertising multiple
global routes. The mobile network is associated with multiple HAs at global routes. The mobile network is simultaneously associated with
any one time. No assumptions are made on whether or not the HAs multiple HAs and a single MNP is available in the NEMO.
belongs to the same administrative domain. However, the MRs
advertises the same MNP.
Each MR may be itself multihomed whereas MNNs are (usually) not The NEMO is multihomed since it has multiple MRs and HAs, but in
multihomed since they would configure a single address on the single addition the conditions detailed in Section 2.1 may also hold for
MNP announced on the link they are attached to. each MR. A bi-directional tunnel would then be established between
each pair of Home Address / Care-of Address.
Regarding MNNs, they are (usually) not multihomed since they would
configure a single global address from the single MNP available on
the link they are attached to.
MR2 AR HA2 MR2 AR HA2
p _ | p _ |
<-_ | |-|_|-| _ <-_ | |-|_|-| _
_ |-|_|-| _____ | |-|_| _ |-|_|-| _____ | |-|_|
|_|-| |-| |-| |_|-| |-| |-|
_ | | | _ | | |
|_|-| _ |-|_____|-| _ |_|-| _ |-|_____|-| _
|-|_|-| | _ |-|_| |-|_|-| | _ |-|_|
<- | |-|_|-| <- | |-|_|-|
p | p |
MNNs MR1 Internet AR HA1 MNNs MR1 Internet AR HA1
Figure 7: (n,n,1): Multiple MRs, Multiple HAs, 1 MNP Figure 7: (n,n,1): Multiple MRs, Multiple HAs, 1 MNP
2.8 (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs 2.8 (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs
The (n,n,n) mobile network has multiple MRs advertising different The (n,n,n) mobile network has multiple MRs advertising different
global routes and different MNPs. The mobile network is associated global routes. The mobile network is simultaneously associated with
with more than one HA at any one time. No assumptions is made on more than one HA and multiple MNPs are available in the NEMO.
whether or not the HA belongs to the same administrative domain.
Each MR may be itself multihomed and MNNs are generally multihomed The NEMO is multihomed since it has multiple MRs and HAs, but in
since they would configure an address on each MNP announced on the addition the conditions detailed in Section 2.1 may also hold for
link they are attached to each MR. A bi-directional tunnel would then be established between
each pair of Home Address / Care-of Address.
Regarding MNNs, they are generally multihomed since they would
configure a global address from each MNP available on the link they
are attached to.
MR2 AR HA2 MR2 AR HA2
p2 _ | p2 _ |
<-_ | |-|_|-| _ <-_ | |-|_|-| _
_ |-|_|-| _____ | |-|_| _ |-|_|-| _____ | |-|_|
|_|-| |-| |-| |_|-| |-| |-|
_ | | | _ | | |
|_|-| _ |-|_____|-| _ |_|-| _ |-|_____|-| _
|-|_|-| | _ |-|_| |-|_|-| | _ |-|_|
<- | |-|_|-| <- | |-|_|-|
p1 | p1 |
MNNs MR1 Internet AR HA1 MNNs MR1 Internet AR HA1
Figure 8: (n,n,n): Multiple MRs, HAs, and MNPs Figure 8: (n,n,n): Multiple MRs, HAs, and MNPs
3. Deployment Scenarios and Prerequisites 3. Deployment Scenarios and Prerequisites
The following generic goals and benefits of multihoming are discussed The following generic goals and benefits of multihoming are discussed
in a companion document [6]: in [6]:
1. Permanent and Ubiquitous Access 1. Permanent and Ubiquitous Access
2. Redundancy/Fault-Recovery 2. Redundancy/Fault-Recovery
3. Load Sharing 3. Load Sharing
4. Load Balancing 4. Load Balancing
5. Preference Settings 5. Preference Settings
These benefits are now illustrated from a NEMO perspective with a These benefits are now illustrated from a NEMO perspective with a
typical instance scenario for each case in the taxonomy. We then typical instance scenario for each case in the taxonomy. We then
discuss the prerequisites to fulfill these. discuss the prerequisites to fulfill these.
3.1 Deployment Scenarios 3.1 Deployment Scenarios
x=1: Multihomed mobile network with a single MR x=1: Multihomed mobile networks with a single MR
o Example: an MR with dual/multiple access interfaces (e.g. o Example: an MR with dual/multiple access interfaces (e.g.
802.11 and GPRS capabilities). This is a S/P-(1,1,*) if both 802.11 and GPRS capabilities). This is a S/P-(1,1,*) if both
accesses are subscribed to the same ISP. If the two accesses accesses are subscribed to the same ISP. If the two accesses
are offered by independent ISPs, this is a S/mP-(1,n,n) [for are offered by independent ISPs, this is a S/mP-(1,n,n) [for
the meaning of this abbreviation, see Appendix A.1]. the meaning of this abbreviation, see Appendix A.1].
Benefits: Ubiquity, Redundancy/Fault-Recovery, Load Sharing, Benefits: Ubiquity, Redundancy/Fault-Recovery, Load Sharing,
Preference Settings Preference Settings
x=N: Multihomed mobile networks with multiple MRs x=N: Multihomed mobile networks with multiple MRs
o Example 1: a train with one MR in each car, all served by the o Example 1: a train with one MR in each car, all served by the
same HA, thus a (n,1,*). Alternatively, the train company same HA, thus a (n,1,*). Alternatively, the train company
might be forced to use different ISPs when the train go to might be forced to use different ISPs when the train go to
different locations, thus it is a (n,n,n). different locations, thus it is a (n,n,n).
Benefits: Load Sharing, Redundancy/Fault-Recovery, Ubiquity Benefits: Load Sharing, Redundancy/Fault-Recovery, Ubiquity
o Example 2: W-PAN with a GPRS_enabled phone and a WiFi-enabled o Example 2: W-PAN with a GPRS-enabled phone and a WiFi-enabled
PDA. This is a S/mP-(n,n,n) if the two access technologies are PDA. This is a S/mP-(n,n,n) if the two access technologies are
subscribed separately. subscribed separately.
Benefits: Ubiquity, Redundancy/Fault-Recovery, Preference Benefits: Ubiquity, Redundancy/Fault-Recovery, Preference
Settings Settings
y=1: Multihomed mobile networks with a single HA y=1: Multihomed mobile networks with a single HA
o Most single ISP cases in above examples. o Most single ISP cases in above examples.
y=N: Multihomed mobile networks with multiple HAs y=N: Multihomed mobile networks with multiple HAs
skipping to change at page 13, line 35 skipping to change at page 14, line 35
o Example: a car with a prefix taken from home (personal traffic o Example: a car with a prefix taken from home (personal traffic
transit on this prefix and is paid by the owner) and one that transit on this prefix and is paid by the owner) and one that
belongs to the car manufacturer (maintenance traffic is paid by belongs to the car manufacturer (maintenance traffic is paid by
the car-manufacturer). This will typically be a (1,1,n) or a the car-manufacturer). This will typically be a (1,1,n) or a
(1,n,n,). (1,n,n,).
Benefits: Preference Settings Benefits: Preference Settings
3.2 Prerequisites 3.2 Prerequisites
In this section, we try to define the requirements in order to In this section, requirements are started in order to comply with the
fulfill the expected multihoming benefits as detailed in [6]. expected benefits of multihoming as detailed in [6].
At least one bi-directional tunnel must be available at any point in At least one bi-directional tunnel must be available at any point in
time between the mobile network and the fixed network to meet all time between the mobile network and the fixed network to meet all
expectations. But for most goals to be effective, multiple tunnels expectations. But for most goals to be effective, multiple tunnels
must be maintained simultaneously: must be maintained simultaneously:
o Permanent and Ubiquitous Access: o Permanent and Ubiquitous Access:
At least one bi-directional tunnel must be available at any point At least one bi-directional tunnel must be available at any point
in time. in time.
o Redundancy and Fault-Recovery: o Redundancy and Fault-Recovery:
Both the inbound and outbound traffic must be transmitted or Both the inbound and outbound traffic must be transmitted or
diverted over another bi-directional tunnel once a bi-directional diverted over another bi-directional tunnel once a bi-directional
tunnel is broken or disrupted. tunnel is broken or disrupted. It should be noted that the
provision of fault tolerance capabilities does not necessarily
require the existence of multiple bi-directional tunnels
simultaneously.
o Load Sharing and Load Balancing: o Load Sharing and Load Balancing:
Multiple tunnels must be maintained simultaneously. Multiple tunnels must be maintained simultaneously.
o Preference Settings: o Preference Settings:
Implicitly, multiple tunnels must be maintained simultaneously if Implicitly, multiple tunnels must be maintained simultaneously if
preferences are set for deciding which of the available preferences are set for deciding which of the available bi-
bi-directional tunnels should be used. A mechanism must be directional tunnels should be used. To allow user/application to
provided to the user/application about the availability of set the preference, a mechanism should be provided to the user/
multiple bi-direction tunnels, and perhaps also to set the application for the notification of the availability of multiple
preference. The preference may reside in the mobile router or bi-directional tunnels, and perhaps also to set preferences.
mobile network nodes (using [9] for instance). Similar mechanism should also be provided to network
administrators for the administration of the preferences.
4. Problem Statement 4. Multihoming Issues
As discussed in the previous section, multiple bi-directional tunnels
need to be maintained either simultaneously (e.g. for load sharing)
or sequentially (e.g. for fault tolerance)
In order to meet the multihoming benefits, multiple tunnels may be
maintained simultaneously (e.g. load balancing, load sharing) or not
(e.g. redundancy) between the mobile network and the fixed network.
In some cases, it may be necessary to divert packets from a (perhaps In some cases, it may be necessary to divert packets from a (perhaps
failed) bi-directional tunnel to an alternative (perhaps newly failed) bi-directional tunnel to an alternative (perhaps newly
established) bi-directional tunnel (i.e. for matters of fault established) bi-directional tunnel (i.e. for matters of fault
recovery, preferences), or to split traffic between multiple tunnel recovery, preferences), or to split traffic between multiple tunnels
(load sharing, load balancing). (load sharing, load balancing).
For doing so, the issues discussed below must be addressed, So, depending on the configuration under consideration, the issues
preferably dynamically. For each issue, we also investigate discussed below may need to be addressed, sometimes dynamically. For
potential ways to solve the problem and recommend which IETF WG(s) each issue, potential ways to solve the problem are investigated and
should look into these issues. an a recommendation is made on which IETF WG(s) should look into
these issues.
4.1 Path Survival 4.1 Fault Tolerance
Internet connectivity is guaranteed for all MNNs as long as at least One of the goals of multihoming is the provision of fault tolerance
one bi-directional tunnel is maintained between the mobile network capabilities. In order to provide such features, a set of tasks need
and the fixed Internet. When an alternative tunnel must be found to to be performed, including: failure detection, alternative available
substitute for the failed one, the loss of one tunnel to the Internet path exploration, path selection, re-homing of established
may result in broken sessions. In this case, new transport sessions communications. These are also discussed in [8] [9]. In the
will have to be established over the alternate tunnel if no mechanism following sub-sections, we look at these issues in the specific
is provided to make this change transparent at layers above layer 3. context of NEMO, rather than the general Multi6/Shim6 perspective in
[8] [9]. In addition, in some scenarios, it may also be required to
provide the mechanisms for coordination between different HAs (see
Section 4.4) and also the coordination between different MRs (see
Section 4.5).
The tunnel can be changed transparently to the MNNs if mechanisms 4.1.1 Failure Detection
such as MMI [10] are brought to the MR.
For instance, in the (1,1,1) case specifically, packets are always It is expected for faults to occur more readily at the edge of the
transmitted to/from the same MR's ingress interface, i.e. network (i.e. the mobile nodes), due to the use of wireless
independently of MR's links connectivity status. connections. Efficient fault detection mechanisms are necessary to
recover in timely fashion. Depending on the NEMO configuration
considered, the failure protection domain greatly varies. In some
configurations, the protection domain provided by NEMO multihoming is
limited to the links between the MR(s) and the HA(s). In other
configurations, the protection domain allows to recover from failures
in other parts of the path, so an end to end failure detection
mechanism is required.
This is a general problem faced by any node with multiple egress Below are detailed which failure detection capabilities are required
paths. It is recommended that this issue be considered by other WGs for each configuration:
(such as IPv6, Multi6), and NEMO WG to contribute any NEMO specific
requirements.
4.2 Path Selection o For the (1,1,*) cases, multiple paths are available between a
single MR and a single HA. All the traffic from and to the NEMO
flows through these MR and HA. Failure detection mechanisms need
only to be executed between these two devices. This is a NEMO
specific issue (MIPv6?).
When multiple bi-directional tunnels are available and possibly used o For the (n,1,*) cases, there is a single HA, so all the traffic
simultaneously, the mode of operation may be either primary-secondary from and to the NEMO will flow through it. The failure detection
(one tunnel is precedent over the others and used as the default mechanisms need to be able to detect failure in the path between
tunnel, while the other serves as a back-up) or peer-to-peer (no the used MR and the only HA. Hence, the failure detection
tunnel has precedence over one another, they are used with the same mechanism needs only to involve the HA and the MRs. This is a
priority). This questions which bi-directional tunnel would be NEMO specific issue (MIPv6?).
selected, and based on which parameter (e.g. type of flow that goes
into/out of the mobile network). o For the (n,n,*) cases, there are multiple paths between the
different HAs and the different MRs. Moreover, the HAs may be
located in different networks, and have different Internet access
links. This implies that changing the HA used, may not only allow
to recover from failures in the link between the HA and the MR but
also from other failure modes, affecting other parts of the path.
In this case, an end to end failure detection mechanism would
provide additional protection. However, a higher number of
failures is likely in the link between the HA and the MR, so it
may be reasonable to provide optimized failure detection
mechanisms for this failure mode even in this scenario, as it is
considered next. The (n,n,1) case, however, seems to be pretty
NEMO specific, because of the absence of multiple prefixes. The
(n,n,n) case is hybrid, since for those cases that selecting a
different prefix results in a change of path, the SHIM/multi6
protocols may be useful. The other cases, are NEMO specific.
In order for fault recovery to work, the MRs and HAs must first
possess a means to detect failures:
o On the MR's side, the MR can rely on router advertisements from
access routers, or other layer-2 trigger mechanisms to detect
faults, e.g. [10], [11], [12] or [13]. (For a related issue, see
Section 4.3.)
o On the HA's side, it is more difficult to detect tunnel failures.
For an ISP deployment model, the HAs and MRs can use proprietary
methods (such as constant transmission of heartbeat signals) to
detect failures and check tunnel liveness. In the S/P model (see
Appendix A.2), a lack of standardized "tunnel liveness" protocol
means that it is harder to detect failures.
A possible method is for the MRs to send binding updates more
regularly with shorter Lifetime values. Similarly, HAs can return
binding acknowledgment messages with smaller Lifetime values, thus
forcing the MRs to send binding updates more frequently. These
binding updates can be used to emulate "tunnel heartbeats". This
however may lead to more traffic and processing overhead, since
binding updates sent to HAs must be protected (and possibly
encrypted) with security associations.
4.1.2 Path Exploration
Once a failure in the currently used path is detected, alternative
paths need to be explored in order to identify an available one.
This process is closely related to failure detection in the sense
that paths being explored need to be alternative paths to the one
that has failed. There are, however, subtle but significant
differences between path exploration and failure detection. Failure
detection occurs on the currently used path while path exploration
occurs in alternative paths (not in the one currently being used for
exchanging packets). Although both path exploration and failure
detection are likely to rely on a reachability or keepalive test
exchange, failure detection also relies on other information, such as
upper layer information (e.g. positive or negative feedback form
TCP), lower layer information (e.g. an interface is down), and
network layer information (e.g. as an address being deprecated or
ICMP error message).
Basically, the same cases as in the analysis of the failure detection
(Section 4.1.1) issue are identified:
o For the (1,1,*) cases, multiple paths are available between a
single MR and a single HA. The existing paths between the HA and
the MR need to be explored to identify an available one. The
mechanism involves only the HA and the MR. This is a NEMO
specific issue (MIPv6?).
o For the (n,1,*) cases, there is a single HA, so all the traffic
from and to the NEMO will flow through it. The available
alternative paths are the different ones between the different MRs
and the HA. The path exploration mechanism needs only to involve
the HA and the MRs. This is a NEMO specific issue (MIPv6?).
o For the (n,n,*) cases, there are multiple paths between the
different HAs and the different MRs. In this case, alternative
paths may be routed completely independently one from each other.
In this case, an end to end path exploration mechanism would be
able to discover if any of the end to end paths is available.
However, a higher number of failures is likely in the link between
the HA and the MR, so it may be reasonable to provide optimized
path exploration mechanism for this failure mode even in this
scenario. The (n,n,1) case, however, seems to be pretty NEMO
specific, because of the absence of multiple prefixes. The
(n,n,n) case is hybrid, since for those cases that selecting a
different prefix result in a change of path, the SHIM/multi6
protocols may be useful. The other cases, are NEMO specific.
4.1.3 Path Selection
A path selection mechanism is required to select among the multiple
available paths. Depending on the NEMO multihoming configuration
involved, the differences between the paths may affect only the part
between the HA and the MR or may affect the full end to end path.
Related to this, depending on the configuration, path selection may
be performed by the HA(s), the MR(s) or the hosts themselves through
address selection, as it will be presented next.
In the (*,*,1) cases, the multiple available paths mostly differ on
the tunnel between the MR and the HA used to carry traffic to/from
the NEMO. In this case, path selection is performed by the MR and
the intra-NEMO routing system for traffic flowing from the NEMO, and
path selection is performed by the HA and intra-Home Network routing
system for traffic flowing to the NEMO, as it is presented next.
A dynamic path selection mechanism is thus needed so that this path A dynamic path selection mechanism is thus needed so that this path
could be selected by: could be selected by:
o The HA: it should be able to select the path based on some o The HA: it should be able to select the path based on some
information recorded in the binding cache. information recorded in the binding cache.
o The MR: it should be able to select the path based on router o The MR: it should be able to select the path based on router
advertisements received on both its egress interfaces or on its advertisements received on both its egress interfaces or on its
ingress interfaces for the (n,*,*) case. ingress interfaces for the (n,*,*) case.
In the (*,*,n) cases, the multiple paths available may differ in more
than just the tunnel between the MR and the HA, since the usage of
different prefixes may result in using different providers, hence in
completely different paths between the involved endpoints. In this
case, besides the mechanisms presented in the previous case,
additional mechanisms for the end to end path selection may be
needed. This mechanism may be closely related to source address
selection mechanisms within the hosts, since selecting a given
address implies selecting a given prefix, which is associated with a
given ISP serving one of the home networks.
In this case we need to consider additional mechanisms for path
selection based on:
o The MNN: it should be able to select the path based on "Default o The MNN: it should be able to select the path based on "Default
Router Selection" (see [Section 6.3.6. Default Router Selection] Router Selection" (see [Section 6.3.6. Default Router Selection]
[11]) in the (n,*,*) case or based on "Source Address Selection" [14]) in the (n,*,*) case or based on "Source Address Selection"
in the (*,*,n) cases (see Section 4.10 of the present memo). in the (*,*,n) cases (see Section 4.8 of the present memo).
o The user or the application: e.g. in case where a user wants to o The user or the application: e.g. in case where a user wants to
select a particular access technology among the available select a particular access technology among the available
technologies for reasons of cost or data rate. technologies for reasons of cost or data rate.
o A combination of any of the above: a hybrid mechanism should be o A combination of any of the above: a hybrid mechanism should be
also available, e.g. one in which the HA, the MR, and/or the MNNs also available, e.g. one in which the HA, the MR, and/or the MNNs
are coordinated to select the path. are coordinated to select the path.
This is a general problem faced by any node with multiple egress When multiple bi-directional tunnels are available and possibly used
paths. It is recommended that this issue be considered by other WGs simultaneously, the mode of operation may be either primary-secondary
(such as IPv6, Multi6), and NEMO WG to contribute any NEMO specific (one tunnel is precedent over the others and used as the default
requirements. tunnel, while the other serves as a back-up) or peer-to-peer (no
tunnel has precedence over one another, they are used with the same
priority). This questions which bi-directional tunnel would be
selected, and based on which parameter (e.g. type of flow that goes
into/out of the mobile network).
4.3 Ingress Filtering The mechanisms for the selection among the different tunnels between
the MR(s) and the HA(s) seems to be quite NEMO specific. The
mechanisms for selecting among different end to end paths based on
address selection are similar to the ones used in other multihoming
scenarios, as those considered by Shim6/multi6 (e.g. [15]).
Ingress filtering mechanisms may drop the outgoing packets when 4.1.4 Re-Homing
multiple bi-directional tunnels end up at different HAs. This could
particularly occur if different MNPs are handled by different home After an outage has been detected and an available alternative path
agents. If packet with a source address configured from a specific has been identified, a re-homing event takes place, diverting the
MNP is tunnelled to a home agent that does not handle that specific existent communications from one path to the other. Similar to the
MNP the packet may be discarded due to ingress filtering (either by previous items involved in this process, the re-homing procedure
the home agent or by a border gateway in the home network). heavily varies depending on the NEMO multihoming configuration.
o For the (*,*,1) configurations, the re-homing procedure involves
only the MR(s) and the HA(s). The re-homing procedure may involve
the exchange of additional BU messages.
These mechanisms are shared between NEMO Basic Support and MIPv6.
o For the (*,*,n) cases, in addition to the previous mechanisms, end
to end mechanisms may be required. Such mechanisms may involve
some form of end to end signaling or may simply rely on using
different addresses for the communication.
The involved mechanisms may be similar to those required for re-
homing Shim6/multi6 communications (e.g. [15]).
4.2 Ingress Filtering
Ingress filtering mechanisms [16][17] may drop the outgoing packets
when multiple bi-directional tunnels end up at different HAs. This
could particularly occur if different MNPs are handled by different
home agents. If a packet with a source address configured from a
specific MNP is tunnelled to a home agent that does not handle that
specific MNP the packet may be discarded either by the home agent or
by a border gateway in the home network.
The ingress filtering compatibility issue is heavily dependent on the
particular NEMO multihoming configuration:
o For the (*,*,1) cases, there is not such an issue, since there is
a single MNP.
o For the (*,1,n) cases, there is not such a problem since there is
a single HA, accepting all the MNPs.
o (*,n,n) are the cases where the ingress filtering presents some
difficulties. In the (1,n,n) case the problem is simplified
because all the traffic from and to the NEMO is routed through a
single MR. Such configuration allows the MR to properly route
packets respecting the constraints imposed by ingress filtering.
The more complex case is the (n,n,n) case. A simplified case
occurs when all the prefixes are accepted by all the HAs, so that
no problems occur with the ingress filtering. However, this
cannot be always assumed, resulting in the problem described
below.
As an example of how this could happen, consider the deployment As an example of how this could happen, consider the deployment
scenario illustrated in Figure 9. In Figure 9, the mobile network scenario illustrated in Figure 9. In Figure 9, the mobile network
has two mobile routers MR1 and MR2, with home agents HA1 and HA2 has two mobile routers MR1 and MR2, with home agents HA1 and HA2
respectively. Two bi-directional tunnels are established are respectively. Two bi-directional tunnels are established between the
established between the two pairs. Each mobile router advertises a two pairs. Each mobile router advertises a different MNP (P1 and
different MNP (P1 and P2). MNP P1 is registered to HA1, and MNP P2 P2). MNP P1 is registered to HA1, and MNP P2 is registered to HA2.
is registered to HA2. Thus, MNNs should be free to auto-configure Thus, MNNs should be free to auto-configure their addresses on any of
their addresses on any of P1 or P2. Ingress filtering could thus P1 or P2. Ingress filtering could thus happen in two cases:
happen in two cases:
o If the two tunnels are available, MNN cannot forward packet with o If the two tunnels are available, MNN cannot forward packet with
source address equals P1.MNN to MR2. This would cause ingress source address equals P1.MNN to MR2. This would cause ingress
filtering at HA2 to occur (or even at MR2). This is contrary to filtering at HA2 to occur (or even at MR2). This is contrary to
normal Neighbor Discovery [11] practice that an IPv6 node is free normal Neighbor Discovery [14] practice that an IPv6 node is free
to choose any router as its default router regardless of the to choose any router as its default router regardless of the
prefix it chooses to use. A simple solution is to require all prefix it chooses to use.
MNNs to set their default router to the MR that advertises the MNP
the MNNs configured their addresses from. If such requirement is
not placed on mobile network nodes, then a multihoming solution
for mobile networks must address this problem. For a possible
approach, see [12]. However, this is not enough to maintain
connectivity if a tunnel fails (see Section 4.1 for a discussion
of this issue).
o If the tunnel to HA1 is broken, packets would be sent through the o If the tunnel to HA1 is broken, packets would be sent through the
tunnel to HA1 are diverted through the tunnel to HA2. If HA2 (or tunnel to HA1 are diverted through the tunnel to HA2. If HA2 (or
some border gateway in the domain of HA2) performs ingress some border gateway in the domain of HA2) performs ingress
filtering, packets with source address configured from MNP P1 may filtering, packets with source address configured from MNP P1 may
be discarded. It should be noted that this problem may be faced be discarded.
by any (*,n,n) mobile network, even if MR1 and MR2 are in fact the
same entity in Figure 9.
To avoid ingress filtering mechanisms dropping packets in such Possible solutions to the ingress filtering incompatibility problem
situations, MR(s) can stop advertising P1. This would prevent MNNs may be based on the following approaches:
from using the address auto-configured on this prefix. However, such
a method suffers from the following two limitations:
o Switching addresses is time consuming since nodes have to wait for o Some form of source address dependent routing, whether host-based
addresses to get deprecated [9]. and/or router-based where the prefix contained in the source
address of the packet is considered when deciding which exit
router to use when forwarding the packet.
o Switching addresses force transport sessions without multihoming o The usage of nested tunnels for (*,n,n) cases. Appendix B
capabilities (such as TCP) to terminate, and be re-established describes one such approach.
using the alternative source address. Transport sessions with
multihoming capabilities (such as SCTP) may be able to continue
without disruption (see also Section 4.1)
Although one way to avoid the long wait for address deprecation by o Deprecating those prefixes associated to non-available exit
sending a router advertisement with zero Lifetime, the routers
termination/disruption of transport sessions may render this solution
unattractive. It is possible to overcome these limitations by using
nested tunnels. Appendix B describes one such approach.
Prefix: P1 +-----+ +----+ +----------+ +-----+ Prefix: P1 +-----+ +----+ +----------+ +-----+
+--| MR1 |--| AR |--| |---| HA1 | +--| MR1 |--| AR |--| |---| HA1 |
| +-----+ +----+ | | +-----+ | +-----+ +----+ | | +-----+
IP: +-----+ | | | Prefix: P1 IP: +-----+ | | | Prefix: P1
P1.MNN or | MNN |--+ | Internet | P1.MNN or | MNN |--+ | Internet |
P2.MNN +-----+ | | | Prefix: P2 P2.MNN +-----+ | | | Prefix: P2
| +-----+ +----+ | | +-----+ | +-----+ +----+ | | +-----+
+--| MR2 |--| AR |--| |---| HA2 | +--| MR2 |--| AR |--| |---| HA2 |
Prefix: P2 +-----+ +----+ +----------+ +-----+ Prefix: P2 +-----+ +----+ +----------+ +-----+
Figure 9: An (n,n,n) mobile network Figure 9: An (n,n,n) mobile network
It is recommended that the NEMO specific issue of ingress filtering The ingress filtering incompatibilities problems that appear in some
be tackled by the NEMO WG, either through the standardization of the NEMO multihoming configurations are similar to those considered in
technique described in Appendix B, or by specifying a statement to Shim6/multi6.
define the mobile router behavior with respect to fault recovery in
an (*,n,n) mobile network.
4.4 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. In order for fault recovery to work, the
MRs and HAs must first possess a means to detect failures:
o On the MR's side, the MR can also rely on router advertisements
from access routers, or other layer-2 trigger mechanisms to detect
faults, e.g. [13] or [14]. (For a related issue, see
Section 4.5.)
o On the HA's side, it is more difficult for HAs to detect tunnel
failures. For an ISP deployment model, the HAs and MRs can use
proprietary methods (such as constant transmission of heartbeat
signals) to detect failures and check tunnel liveness. In the S/P
model (see Appendix A.2), a lack of standardized "tunnel liveness"
protocol means that it is harder to detect failures.
A possible method is for the MRs to send binding updates more
regularly with shorter Lifetime values. Similarly, HAs can return
binding acknowledgment messages with smaller Lifetime values, thus
forcing the MRs to send binding updates more frequently. These
binding updates can be used to emulate "tunnel heartbeats". This
however may lead to more traffic and processing overhead, since
binding updates sent to HAs must be protected (and possibly
encrypted) with security associations.
There are other failure modes to consider as well, such as failure at
home agent, failure at access routers, or in general failure of a
link or node along the path from the mobile router to the home agent.
By the nature of the routing infrastructure, failure of intermediate
nodes or links are recovered by the the routing infrastructure by
choosing a different route. For those failures that can't be
receovered (such a failure of the access router), a heartbeat
protocol or the use of small-lifetime binding updates described above
can also be used to detect tunnel failures.
This is a general problem faced by all nodes communicating with a
peer. It is recommended that NEMO WG adopts any failure detection
mechansim standardized in the IETF, and, should the need arise,adapts
such mechanism specifically for detecting tunnel failures.
4.5 Media Detection 4.3 Media Detection
In order to achieve benefits such as ubiquity or fault recovery, it In order to achieve benefits such as ubiquity or fault recovery, it
is necessary for mobile router to detect the availability of network is necessary for the mobile router to detect the availability of
media. This may be achieved using layer 2 triggers [13], or other network media. This may be achieved using layer 2 triggers [10], or
mechanism developed/recommended by the Detecting Network Attachment other mechanism developed/recommended by the Detecting Network
(DNA) Working Group. Attachment (DNA) Working Group [11][18].
This is related to Section 4.4, since the ability to detect media This is related to Section 4.1.1, since the ability to detect media
availability would often implies the ability to detect media availability would often implies the ability to detect media un-
in-availability. availability.
4.6 HA Synchronization 4.4 HA Synchronization
In the (*,n,1) mobile networks, a single MNP would be registered at In the (*,n,*) mobile networks, a single MNP would be registered at
different HAs. This gives rise to the following issues: different HAs. This gives rise to the following cases:
o Only one HA may actively advertise a route to the MNP. o Only one HA may actively advertise a route to the MNP,
o Multiple HAs at different domains may advertise a route to the o Multiple HAs at different domains may advertise a route to the
same MNP same MNP
This may pose a problem in the routing infrastructure as a whole. This may pose a problem in the routing infrastructure as a whole if
The implications of this aspect needs further exploration. Certain the HAs are located in different administrative domains. The
level of HA co-ordination may be required. A possible approach is to implications of this aspect needs further exploration. Certain level
adopt a HA synchronization mechanism such as that described in [15] of HA co-ordination may be required. A possible approach is to adopt
and [16]. Such synchronization might also be necessary in a (*,n,*) a HA synchronization mechanism such as that described in [19] and
[20]. Such synchronization might also be necessary in a (*,n,*)
mobile network, when a MR sends binding update messages to only one mobile network, when a MR sends binding update messages to only one
HA (instead of all HAs). In such cases, the binding update HA (instead of all HAs). In such cases, the binding update
information might have to be synchronized betweeen HAs. The mode of information might have to be synchronized between HAs. The mode of
synchoronization may be either primary-secondary or peer-to-peer. synchronization may be either primary-secondary or peer-to-peer. In
See also Section 4.7. addition, when MNP is delegated to the MR (see Section 4.6), some
level of co-ordination between the HAs may also be neceesary.
This problem is general in the sense that Mobile IPv6 will have to This issue is a general mobility issue that will also have to be
consider similar issues. It is recommended that the issue be looked dealt with Mobile IPv6. This issue should be dealt within a
at in one of the Mobile IP WG, and NEMO WG to contribute any NEMO potentially forthcoming Monami6 WG.
specific requirements.
4.7 MR Synchronization 4.5 MR Synchronization
In the (n,*,*) mobile network, different MRs may need to be In the (n,*,*) mobile network, different MRs may need to be
synchronized in order to take common decisions. The mode of synchronized in order to take common decisions. The mode of
synchoronization may be either primary-secondary or peer-to-peer. synchronization may be either primary-secondary or peer-to-peer.
This may include: This may include:
o In the (n,*,1) case, advertising the same MNP (see also "prefix o In the (n,*,1) case, advertising the same MNP (see also "prefix
delegation" in Section 4.8). delegation" in Section 4.6).
o In the (n,*,n) case, a MR relaying the advertisement of the MNP o In the (n,*,n) case, a MR relaying the advertisement of the MNP
from another failed MR. from another failed MR.
o In the (n,*,*) cases, relaying between MRs everything that needs o In the (n,*,*) cases, relaying between MRs everything that needs
to be relayed, such as data packets, creating a tunnel from the to be relayed, such as data packets, creating a tunnel from the
ingress interface, etc. ingress interface, etc.
This problem is general in the sense that a multi-router site would This problem is general in the sense that a multi-router site in the
require the same level of router synchronization as well. It is fixed network would require the same level of router synchronization.
recommended that the issue be looked at in IPv6 or Multi6 WG, and It is recommended that the issue be looked at in the IPv6 or Shim6
NEMO WG to contribute any NEMO specific requirements. WG, and the NEMO WG to contribute any NEMO specific requirement.
4.8 Prefix Delegation 4.6 Prefix Delegation
In the (*,*,1) mobile network, the same MNP must be advertised to the In the (*,*,1) mobile network, the same MNP must be advertised to the
MNNs through different paths. This questions how to perform prefix MNNs through different paths. This questions how to perform prefix
delegation: delegation:
o For the (*,n,1) mobile network, how multiple HAs would delegate o For the (*,n,1) mobile network, how multiple HAs would delegate
the same MNP to the mobile network. For doing so, the HAs may be the same MNP to the mobile network. For doing so, the HAs may be
somehow configured to advertise the same MNP. (see also "HA somehow configured to advertise the same MNP. (see also "HA
Synchronization" in Section 4.6). Synchronization" in Section 4.4).
o For the (n,*,n) mobile network, how multiple mobile routers would o For the (n,*,n) mobile network, how multiple mobile routers would
be synchronized to advertise the same MNP down the NEMO-link. For be synchronized to advertise the same MNP down the NEMO-link. For
doing so, the MRs may be somehow configured to advertise the same doing so, the MRs may be somehow configured to advertise the same
MNP (see also "MR Synchronization" in Section 4.7). MNP (see also "MR Synchronization" in Section 4.5).
This could be configured manually, or dynamically. Alternatively, This could be configured manually, or dynamically. Alternatively,
prefix delegation mechanisms [17][18] could be used to ensure all prefix delegation mechanisms [21] [22] could be used to ensure all
routers advertise the same MNP. routers advertise the same MNP.
Prefix delegation is currently being explored in the NEMO WG. Should Prefix delegation is currently being explored in the NEMO WG. Should
the WG decides to standardize a prefix delegation mechanism, the WG the WG decides to standardize a prefix delegation mechanism, the WG
should also consider its application to a multihomed mobile network. should also consider its application to a multihomed mobile network.
4.9 Multiple Bindings/Registrations 4.7 Multiple Bindings/Registrations
When a MR is configured with multiple Care-of Addresses, it is often When a MR is configured with multiple Care-of Addresses, it is often
necessary for it to bind these Care-of Addresses to the same MNP. necessary for it to bind these Care-of Addresses to the same MNP.
This is a generic issue, since Mobile IPv6 nodes face a similar This is a generic mobility issue, since Mobile IPv6 nodes face a
problem if they wish to bind multiple Care-of Addresses to the same similar problem. This issue is discussed in [7]. It is sufficient
Home Address". This is better discussed in [7]. It is sufficient to to note that solutions like [23] can solve this for both Mobile IPv6
note that solutions like [19] can solve this. and NEMO Basic Support. This issue should be dealt within a
potentially forthcoming Monami6 WG.
4.10 Source Address Selection 4.8 Source Address Selection
In the (*,*,n) mobile networks, MNNs would be configured with In the (*,*,n) mobile networks, MNNs would be configured with
multiple addresses. Source address selection mechanisms are needed multiple addresses. Source address selection mechanisms are needed
to decide which address to choose from. to decide which address to choose from.
It may be desirable for MNN to be able to acquire "preference" In addition, source address selection may be closely related to path
information on each MNP from the MRs. This allows default address selection procedures (see Section 4.1.3) and re-homing techniques
selection mechanism such as that specified in [9] to be used. (see Section 4.1.4).
Further exploration on setting such "preference" information in
Router Advertisement based on performance of the bi-directional It may be desirable for MNNs to be able to acquire "preference"
information on each MNP from the MRs. This would allow default
address selection mechanisms such as these specified in [24] to be
used. Further exploration on setting such "preference" information
in Router Advertisement based on performance of the bi-directional
tunnel might prove to be useful. tunnel might prove to be useful.
This is a general issue faced by any node when offered multiple This is a general issue faced by any node when offered multiple
prefixes. It is recommended that the issue be examined by other WG prefixes. It is recommended that the issue be examined by other WG
(such as IPv6). (such as IPv6).
4.11 Impact on the Routing Infrastructure 4.9 Loop Prevention in Nested Mobile Networks
In the (1,n,1) case with HAs located in distinct ISPs/ASs, multiple
routes directed to the mobile network may be advertised in the
Internet. Although this may provide shorter paths, it would add a
burden to routing tables as multiple routes to the same prefix are
injected into the routing infrastructure.
Such issues are investigated in the MULTI6 working group at the IETF,
and the NEMO WG should adopt solutions designed there whenever
appropriate.
4.12 Nested Mobile Networks
When a multihomed mobile network is nested within another mobile When a multihomed mobile network is nested within another mobile
network, it can result in very complex topologies. For instance, a network, it can result in very complex topologies. For instance, a
nested mobile network may be attached two different root-MRs, thus nested mobile network may be attached two different root-MRs, thus
the aggregated network no longer forms a simple tree structure. As the aggregated network no longer forms a simple tree structure. As
such, a solution to prevent an infinite loop of multiple mobile such, a solution to prevent an infinite loop of multiple mobile
routers must be provided. routers must be provided.
This problem is specific to NEMO WG. It is recommended that the NEMO This problem is specific to NEMO Basic Support. It is recommended
WG standardizes a solution to solve this problem (such as the use of that the NEMO WG standardizes a solution to solve this problem (such
a tree-spanning algorithm). as the use of a tree-spanning algorithm, or [25]).
4.13 Split Mobile Networks 4.10 Prefix Ownership
When a (n,*,1) network splits, (i.e. the two MRs split themselves When a (n,*,1) network splits, (i.e. the two MRs split themselves
up), the only available MNP will then be registered by two different up), MRs on distinct links may try to register the only available
MRs on different links. This cannot be allowed, as the HA has no way MNP. This cannot be allowed, as the HA has no way to know which node
to know which node with an address configured from that MNP is with an address configured from that MNP is attached to which MR.
attached to which MR. Some mechanism must be present for the MNP to Some mechanism must be present for the MNP to either be forcibly
either be forcibly removed from one (or all) MRs, or the implementors removed from one (or all) MRs, or the implementors must not allow a
must not allow a (n,*,1) network to split. (n,*,1) network to split.
A possible approach to solving this problem is described in [20].
This problem is specific to NEMO WG. It is recommended that the NEMO A possible approach to solving this problem is described in [26].
WG standardizes a solution to solve this problem, or specifies that
the split of a (n,*,1) network cannot be allowed without a router
renumbering.
5. Conclusion This problem is specific to NEMO Basic Support. It is recommended
that the NEMO WG standardizes a solution to solve this problem, or
specifies that the split of a (n,*,1) network cannot be allowed
without a router renumbering.
This document is an analysis of multihoming in the context of network 5. Matrix [Issues,(x,y,z) Configuration]
mobility. The purpose of this memo is to investigate issues related
to such a bi-directional tunneling mechanism when mobile networks are
multihomed.
Several issues that might impact the deployment of NEMO with Several issues that might impact the deployment of NEMO with
multihoming capabilities were identified in Section 4. They include multihoming capabilities were identified in Section 4. These are
: shown in the matrix below, for each of the eight multihoming
configurations, together with indications of the WG(s) in which each
1. Path Survival issue is the most likely to be solved.
2. Path Availability
3. Ingress Filtering
4. Failure Detection
5. Media Detection
6. HA Synchronization
7. MR Synchronization
8. Prefix Delegation +=================================================================+
| # of MRs: | 1 | 1 | 1 | 1 | n | n | n | n |
| # of HAs: | 1 | 1 | n | n | 1 | 1 | n | n |
| # of Prefixes: | 1 | n | 1 | n | 1 | n | 1 | n |
+=================================================================+
| Fault Tolerance | * | * | * | * | * | * | * | * |
+---------------------------------+---+---+---+---+---+---+---+---+
| Failure Detection |N/M|N/M|N/M|N/M|N/M|N/M| N | S |
+---------------------------------+---+---+---+---+---+---+---+---+
| Path Exploration |N/M|N/M|N/M|N/M|N/M|N/M| N | S |
+---------------------------------+---+---+---+---+---+---+---+---+
| Path Selection | N |S/N| N |S/N| N |S/N| N |S/N|
+---------------------------------+---+---+---+---+---+---+---+---+
| Re-Homing |N/M| S |N/M| S |N/M| S |N/M| S |
+---------------------------------+---+---+---+---+---+---+---+---+
| Ingress Filtering | . | . | . | t | . | . | . | N |
+---------------------------------+---+---+---+---+---+---+---+---+
| Media Detection | D | D | D | D | D | D | D | D |
+---------------------------------+---+---+---+---+---+---+---+---+
| HA Synchronization | . | . |N/M|N/M| . | . |N/M|N/M|
+---------------------------------+---+---+---+---+---+---+---+---+
| MR Synchronization | . | . | . | . | G | G | G | G |
+---------------------------------+---+---+---+---+---+---+---+---+
| Prefix Delegation | . | . | N | N | N | N | N | N |
+---------------------------------+---+---+---+---+---+---+---+---+
| Multiple Binding/Registrations | M | M | M | M | M | M | M | M |
+---------------------------------+---+---+---+---+---+---+---+---+
| Source Address Selection | . | G | . | G | . | G | . | G |
+---------------------------------+---+---+---+---+---+---+---+---+
| Loop Prevention in Nested NEMO | N | N | N | N | N | N | N | N |
+---------------------------------+---+---+---+---+---+---+---+---+
| Prefix Ownership | . | . | . | . | N | . | N | . |
+=================================================================+
N - NEMO Specific M - MIPv6 Specific G - Generic IPv6
S - SHIM6 WG D - DNA WG
. - Not an Issue t - trivial
* - Fault Tolerance is a combination of Failure Detection, Path
Exploration, Path Selection, and Re-Homing
9. Multiple Binding/Registrations 6. Conclusion
10. Source Address Selection This memo is an analysis of multihoming in the context of network
mobility under the operation of NEMO Basic Support. The purpose of
this memo is to investigate issues related to such a bi-directional
tunneling mechanism when mobile networks are multihomed. For doing
so, a taxonomy was proposed to classify the mobile networks in eight
possible multihomed configurations. The issue were explained and
were then summarized in a table showing under which multihoming
configuration it applies, and which IETF working group is the best
chartered to solve it. This analysis will be helpful to extend the
existing standards to support multihoming and to implementors of NEMO
Basic Support and multihoming-related mechanisms.
11. Imapct on the Routing Infrastructure 7. IANA Considerations
12. Nested Mobile Networks This is an informational document and does not require any IANA
action.
13. Split Mobile Networks. 8. Security Considerations
This study is a work in progress and need to be improved by a This is an informational document where the multihoming
thorough study of each individual issues. Particularly, this memo configurations under the operation of NEMO Basic Support are
should be completed by a thorough threat analysis of multihoming analyzed. Security considerations of these multihoming
configurations of mobile network. We will add security threat issues configurations, should they be different from those that concern NEMO
here as and when they are encountered, such as those described in Basic Support, must be considered by forthcoming solutions.
[21]. We also encourage interested people to contribute to this
part.
6. Acknowledgments 9. Acknowledgments
The authors would like to thank people who have given valuable The authors would like to thank people who have given valuable
comments on various multihoming issues on the mailing list, and also comments on various multihoming issues on the mailing list, and also
those who have suggested directions in the 56th - 61st IETF Meetings. those who have suggested directions in the 56th - 61st IETF Meetings.
Sincere gratitude is also extended to Marcelo Bagnulo Braun for his The initial evaluation of NEMO Basic Support is a contribution from
extensive review and comments on the -00 version of this draft. The
initial evaluation of NEMO Basic Support is a contribution from
Julien Charbon. Julien Charbon.
7. References 10. References
10.1 Normative References
[1] Ernst, T., "Network Mobility Support Goals and Requirements", [1] Ernst, T., "Network Mobility Support Goals and Requirements",
Internet-Draft draft-ietf-nemo-requirements-04, February 2005. draft-ietf-nemo-requirements-04 (work in progress),
February 2005.
[2] Manner, J. and M. Kojo, "Mobility Related Terminology", [2] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[3] Ernst, T. and H. Lach, "Network Mobility Support Terminology", [3] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
Internet-Draft draft-ietf-nemo-terminology-03, February 2005. draft-ietf-nemo-terminology-03 (work in progress),
February 2005.
[4] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubert, [4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005. January 2005.
[5] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[6] Ernst, T., Montavont, N. and R. Wakikawa, "Goals and Benefits 10.2 Informative References
of Multihoming",
Internet-Draft draft-ernst-generic-goals-and-benefits-01,
February 2005.
[7] Montavont, N., Wakikawa, R. and T. Ernst, "Analysis of [6] Ernst, T., "Goals and Benefits of Multihoming",
Multihoming in Mobile IPv6", draft-multihoming-generic-goals-and-benefits-00 (work in
, January 2005. progress), February 2004.
[8] Ernst, T. and J. Charbon, "Multihoming with NEMO Basic [7] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K.
Support", Proceedings First International Conference on Mobile Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
Computing and Ubiquitous Networking (ICMU), January 2004. draft-montavont-mobileip-multihoming-pb-statement-04 (work in
progress), June 2005.
[9] Draves, R., "Default Address Selection for Internet Protocol [8] Arkko, J., "Failure Detection and Locator Selection Design
version 6 (IPv6)", RFC 3484, February 2003. Considerations", draft-ietf-shim6-failure-detection-00 (work in
progress), July 2005.
[10] Montavont, N., Noel, T. and M. Kassi-Lahlou, "MIPv6 for [9] Beijnum, I., "Shim6 Reachability Detection",
Multiple Interfaces", draft-ietf-shim6-reach-detect-00 (work in progress), July 2005.
Internet-Draft draft-montavont-mobileip-mmi-00, July 2002.
[11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery [10] Yegin, A., "Link-layer Event Notifications for Detecting
for IP Version 6 (IPv6)", RFC 2461, December 1998. Network Attachments", draft-ietf-dna-link-information-01 (work
in progress), February 2005.
[12] Draves, R. and D. Thaler, "Default Router Preferences and [11] Narayanan, S., "Detecting Network Attachment in IPv6 - Best
More-Specific Routes", Current Practices for hosts.", draft-ietf-dna-hosts-00 (work in
Internet-Draft draft-ietf-ipv6-router-selection-06, October progress), April 2005.
2004.
[13] Yegin, A., "Link-layer Hints for Detecting Network [12] Yegin, A., "Link-layer Hints for Detecting Network
Attachments", Internet-Draft draft-yegin-dna-l2-hints-01, Attachments", draft-yegin-dna-l2-hints-01 (work in progress),
February 2004. February 2004.
[14] Yegin, A., "Supporting Optimized Handover for IP Mobility [13] Yegin, A., "Supporting Optimized Handover for IP Mobility
-Requirements for Underlying Systems", -Requirements for Underlying Systems",
Internet-Draft draft-manyfolks-l2-mobilereq-02, July 2002. draft-manyfolks-l2-mobilereq-02 (work in progress), July 2002.
[15] Wakikawa, R., Devarapalli, V. and P. Thubert, "Inter Home [14] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
Agents Protocol (HAHA)", for IP Version 6 (IPv6)", RFC 2461, December 1998.
Internet-Draft draft-wakikawa-mip6-nemo-haha-01, February 2004.
[16] Koh, B., Ng, C. and J. Hirano, "Dynamic Inter Home Agent [15] Bagnulo, M. and J. Arkko, "Functional decomposition of the
Protocol", Internet-Draft draft-koh-mip6-nemo-dhap-00, July multihoming protocol", draft-ietf-shim6-functional-dec-00 (work
2004. in progress), July 2005.
[17] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix [16] 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.
[17] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[18] Narayanan, S., "Detecting Network Attachment in IPv6 - Best
Current Practices for Routers", draft-ietf-dna-routers-00 (work
in progress), July 2005.
[19] Wakikawa, R., Devarapalli, V., and P. Thubert, "Inter Home
Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work
in progress), February 2004.
[20] Koh, B., Ng, C., and J. Hirano, "Dynamic Inter Home Agent
Protocol", draft-koh-mip6-nemo-dhap-00 (work in progress),
July 2004.
[21] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
Delegation", RFC 3769, June 2004. Delegation", RFC 3769, June 2004.
[18] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", [22] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO",
Internet-Draft draft-droms-nemo-dhcpv6-pd-01, February 2004. draft-droms-nemo-dhcpv6-pd-02 (work in progress), April 2005.
[19] Wakikawa, R., Uehara, K., Ernst, T. and K. Nagami, "Multiple [23] Wakikawa, R., Uehara, K., Ernst, T., and K. Nagami, "Multiple
Care-of Addresses Registration", Care-of Addresses Registration",
Internet-Draft draft-wakikawa-mobileip-multiplecoa-04, February draft-wakikawa-mobileip-multiplecoa-04 (work in progress),
2005. June 2005.
[20] Kumazawa, M., "Token based Duplicate Network Detection for [24] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[25] Thubert, P., "Nested Nemo Tree Discovery",
draft-thubert-tree-discovery-02 (work in progress), July 2005.
[26] Kumazawa, M., "Token based Duplicate Network Detection for
split mobile network (Token based DND)", split mobile network (Token based DND)",
Internet-Draft draft-kumazawa-nemo-tbdnd-01, October 2004. draft-kumazawa-nemo-tbdnd-02 (work in progress), July 2005.
[21] Choi, S., "Threat for Multi-homed Mobile Networks", [27] Choi, S., "Threat for Multi-homed Mobile Networks",
Internet-Draft draft-cho-nemo-threat-multihoming-00, February draft-cho-nemo-threat-multihoming-00 (work in progress),
2004. February 2004.
[28] Montavont, N., Noel, T., and M. Kassi-Lahlou, "MIPv6 for
Multiple Interfaces", draft-montavont-mobileip-mmi-00 (work in
progress), July 2002.
[29] Draves, R. and D. Thaler, "Default Router Preferences and More-
Specific Routes", draft-ietf-ipv6-router-selection-07 (work in
progress), January 2005.
Authors' Addresses Authors' Addresses
Chan-Wah Ng Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530 Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate Tai Seng Industrial Estate
Singapore 534415 Singapore 534415
SG SG
Phone: +65 65505420 Phone: +65 65505420
Email: cwng@psl.com.sg Email: chanwah.ng@sg.panasonic.com
Eun Kyoung Paik Eun Kyoung Paik
KT KT
Portable Internet Team, Convergence Lab., KT Portable Internet Team, Convergence Lab., KT
17 Woomyeon-dong, Seocho-gu 17 Woomyeon-dong, Seocho-gu
Seoul 137-792 Seoul 137-792
Korea Korea
Phone: +82-2-526-5233 Phone: +82-2-526-5233
Fax: +82-2-526-5200 Fax: +82-2-526-5200
skipping to change at page 27, line 5 skipping to change at page 31, line 16
Jun Murai Lab., Keio University. Jun Murai Lab., Keio University.
K-square Town Campus, 1488-8 Ogura, Saiwa-Ku K-square Town Campus, 1488-8 Ogura, Saiwa-Ku
Kawasaki, Kanagawa 212-0054 Kawasaki, Kanagawa 212-0054
Japan Japan
Phone: +81-44-580-1600 Phone: +81-44-580-1600
Fax: +81-44-580-1437 Fax: +81-44-580-1437
Email: ernst@sfc.wide.ad.jp Email: ernst@sfc.wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~ernst/ URI: http://www.sfc.wide.ad.jp/~ernst/
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 8837
Email: marcelo@it.uc3m.es
Appendix A. Alternative Classifications Approach Appendix A. Alternative Classifications Approach
A.1 Ownership-Oriented Approach A.1 Ownership-Oriented Approach
An alternative approach to classifying multihomed mobile network is An alternative approach to classifying multihomed mobile network is
proposed by Erik Nordmark (Sun Microsystems) by breaking the proposed by Erik Nordmark (Sun Microsystems) by breaking the
classification of multihomed network based on ownership. This is classification of multihomed network based on ownership. This is
more of a tree-like top-down classification. Starting from the more of a tree-like top-down classification. Starting from the
control and ownership of the HA(s) and MR(s), there are two different control and ownership of the HA(s) and MR(s), there are two different
possibilities: either (i) the HA(s) and MR(s) are controlled by a possibilities: either (i) the HA(s) and MR(s) are controlled by a
skipping to change at page 29, line 14 skipping to change at page 34, line 16
MNP MNP
o S/mP-(1,n,n): Multiple Providers, Single MR, Multiple HAs, o S/mP-(1,n,n): Multiple Providers, Single MR, Multiple HAs,
Multiple MNPs Multiple MNPs
o S/mP-(n,n,n): Multiple Providers, Multiple MRs, Multiple HAs, o S/mP-(n,n,n): Multiple Providers, Multiple MRs, Multiple HAs,
Multiple MNPs Multiple MNPs
When the HA(s) and MR(s) are controlled by different entities, it is When the HA(s) and MR(s) are controlled by different entities, it is
more likely the scenario where the MR is controlled by one entity more likely the scenario where the MR is controlled by one entity
(i.e. the subscriber), and the MR is establishing multiple (i.e. the subscriber), and the MR is establishing multiple bi-
bi-directional tunnels to one or more HA(s) provided by one or more directional tunnels to one or more HA(s) provided by one or more
ISP(s). In such case, it is unlikely for the ISP to run IGP over the ISP(s). In such case, it is unlikely for the ISP to run IGP over the
bi-directional tunnel, since ISP would most certainly wish to retain bi-directional tunnel, since ISP would most certainly wish to retain
full control of its routing domain. full control of its routing domain.
A.2 Problem-Oriented Approach A.2 Problem-Oriented Approach
A third approach is proposed by Pascal Thubert (Cisco System). This A third approach is proposed by Pascal Thubert (Cisco System). This
focused on the problems of multihomed mobile networks rather than the focused on the problems of multihomed mobile networks rather than the
configuration or ownership. With this approach, there is a set of 4 configuration or ownership. With this approach, there is a set of 4
categories based on two orthogonal parameters: the number of HAs, and categories based on two orthogonal parameters: the number of HAs, and
skipping to change at page 31, line 21 skipping to change at page 36, line 21
interface is down, it should detect if any other alternate route to interface is down, it should detect if any other alternate route to
the global Internet exists. This alternate route may be provided by the global Internet exists. This alternate route may be provided by
any other MRs connected to one of its ingress interfaces that has an any other MRs connected to one of its ingress interfaces that has an
independent route to the global Internet, or by another active egress independent route to the global Internet, or by another active egress
interface the MR itself possess. If such an alternate route exists, interface the MR itself possess. If such an alternate route exists,
the MR should re-establish the bi-directional tunnel using this the MR should re-establish the bi-directional tunnel using this
alternate route. alternate route.
In the remaining part of this section, we will attempt to investigate In the remaining part of this section, we will attempt to investigate
methods of performing such re-establishment of bi-directional methods of performing such re-establishment of bi-directional
tunnels. It is not the objective of this memo to specify a new tunnels. This method of tunnel re-estblishment is particularly
protocol specifically tailored to provide this form of re- useful for the (*,n,n) NEMO configuration. It is not the objective
establishments. Instead, we will limit ourselves to currently of this memo to specify a new protocol specifically tailored to
available mechanisms specified in Mobile IPv6 [5] and Neighbor provide this form of re- establishments. Instead, we will limit
Discovery in IPv6 [11]. ourselves to currently available mechanisms specified in Mobile IPv6
[5] and Neighbor Discovery in IPv6 [14].
B.1 Detecting Presence of Alternate Routes B.1 Detecting Presence of Alternate Routes
To actively utilize the robustness provided by multihoming, a MR must To actively utilize the robustness provided by multihoming, a MR must
first be capable of detecting alternate routes. This can be manually first be capable of detecting alternate routes. This can be manually
configured into the MR by the administrators if the configuration of configured into the MR by the administrators if the configuration of
the mobile network is relatively static. It is however highly the mobile network is relatively static. It is however highly
desirable for MRs to be able to discover alternate routes desirable for MRs to be able to discover alternate routes
automatically for greater flexibility. automatically for greater flexibility.
skipping to change at page 31, line 51 skipping to change at page 36, line 52
to detect the presence of other MR. A MR can do so by listening for to detect the presence of other MR. A MR can do so by listening for
Router Advertisement message on its *ingress* interfaces. When a MR Router Advertisement message on its *ingress* interfaces. When a MR
receives a Router Advertisement message with a non-zero Router receives a Router Advertisement message with a non-zero Router
Lifetime field from one of its ingress interfaces, it knows that Lifetime field from one of its ingress interfaces, it knows that
another MR which can provide an alternate route to the global another MR which can provide an alternate route to the global
Internet is present in the mobile network. Internet is present in the mobile network.
B.2 Re-Establishment of Bi-Directional Tunnels B.2 Re-Establishment of Bi-Directional Tunnels
When a MR detects that the link by which its current bi-directional When a MR detects that the link by which its current bi-directional
tunnel with its HA is using is down, it needs to re-establish the tunnel with its HA is using is down, it needs to re-establish the bi-
bi-directional tunnel using an alternate route detected. We consider directional tunnel using an alternate route detected. We consider
two separate cases here: firstly, the alternate route is provided by two separate cases here: firstly, the alternate route is provided by
another egress interface that belongs to the MR; secondly, the another egress interface that belongs to the MR; secondly, the
alternate route is provided by another MR connected to the mobile alternate route is provided by another MR connected to the mobile
network. We refer to the former case as an alternate route provided network. We refer to the former case as an alternate route provided
by an alternate egress interface, and the latter case as an alternate by an alternate egress interface, and the latter case as an alternate
route provided by an alternate MR. route provided by an alternate MR.
B.2.1 Using Alternate Egress Interface B.2.1 Using Alternate Egress Interface
When an egress interface of a MR loses the connection to the global When an egress interface of a MR loses the connection to the global
skipping to change at page 32, line 26 skipping to change at page 37, line 27
do so is for the mobile router to send a binding update to the home do so is for the mobile router to send a binding update to the home
agent of the failed interface using the Care-of Address assigned to agent of the failed interface using the Care-of Address assigned to
the alternate interface in order to re-establish the bi-directional the alternate interface in order to re-establish the bi-directional
tunneling using the Care-of Address on the alternate egress tunneling using the Care-of Address on the alternate egress
interface. After a successful binding update, the MR encapsulates interface. After a successful binding update, the MR encapsulates
outgoing packets through the bi-directional tunnel using the outgoing packets through the bi-directional tunnel using the
alternate egress interface. alternate egress interface.
The idea is to use the global address (most likely a Care-of Address) The idea is to use the global address (most likely a Care-of Address)
assigned to an alternate egress interface as the new (back-up) assigned to an alternate egress interface as the new (back-up)
Care-of Address of the mobile router to re-establish the Care-of Address of the mobile router to re-establish the bi-
bi-directional tunneling with its home agent. directional tunneling with its home agent.
B.2.2 Using Alternate Mobile Router B.2.2 Using Alternate Mobile Router
When the MR loses a connection to the global Internet, the MR can When the MR loses a connection to the global Internet, the MR can
utilize a route provided by an alternate MR (if one exists) to utilize a route provided by an alternate MR (if one exists) to re-
re-establish the bi-directional tunnel with its HA. First, the MR establish the bi-directional tunnel with its HA. First, the MR has
has to obtain a Care-of Address from the alternate MR (i.e. attaches to obtain a Care-of Address from the alternate MR (i.e. attaches
itself to the alternate MR). Next, it sends binding update to its HA itself to the alternate MR). Next, it sends binding update to its HA
using the Care-of Address obtained from the alternate MR. From then using the Care-of Address obtained from the alternate MR. From then
on, the MR can encapsulates outgoing packets through the on, the MR can encapsulates outgoing packets through the bi-
bi-directional tunnel using via the alternate MR. directional tunnel using via the alternate MR.
The idea is to obtain a Care-of Address from the alternate MR and use The idea is to obtain a Care-of Address from the alternate MR and use
this as the new (back-up) Care-of Address of the MR to re-establish this as the new (back-up) Care-of Address of the MR to re-establish
the bi-directional tunneling with its HA. the bi-directional tunneling with its HA.
Note that every packet sent between MNNs and their correspondent Note that every packet sent between MNNs and their correspondent
nodes will experience two levels of encapsulation. First level of nodes will experience two levels of encapsulation. First level of
tunneling occurs between a MR which the MNN uses as its default tunneling occurs between a MR which the MNN uses as its default
router and the MR's HA. The second level of tunneling occurs between router and the MR's HA. The second level of tunneling occurs between
the alternate MR and its HA. the alternate MR and its HA.
skipping to change at page 34, line 13 skipping to change at page 39, line 13
things are back to square one). things are back to square one).
Appendix C. Change Log Appendix C. Change Log
o This draft is an update of draft-ng-nemo-multihoming-issues-03.txt o This draft is an update of draft-ng-nemo-multihoming-issues-03.txt
which is itself a merge of 3 previous drafts which is itself a merge of 3 previous drafts
draft-ng-nemo-multihoming-issues-02.txt, draft-ng-nemo-multihoming-issues-02.txt,
draft-eun-nemo-multihoming-problem-statement-00.txt, and draft-eun-nemo-multihoming-problem-statement-00.txt, and
draft-charbon-nemo-multihoming-evaluation-00.txt draft-charbon-nemo-multihoming-evaluation-00.txt
o Changes from draft-ietf-nemo-multihoming-issues-02 to -03:
* Enlisted Marcelo Bagnulo as co-author
* Restructuring of Section 4:
+ Re-named 'Path Survival' to 'Fault Tolerance'
+ Moved 'Path Failure Detection' and 'Path Selection' as sub-
issues of 'Fault Tolerance'
+ Added 'Path Exploration' and 'Re-homing' as sub-issues of
'Fault Tolerance'
+ Removed 'Impact on Routing Infrastructure'
* Breaking references into Normative and Informative
o Changes from draft-ietf-nemo-multihoming-issues-01 to -02: o Changes from draft-ietf-nemo-multihoming-issues-01 to -02:
* Added recommendations/suggestion of which WG each issue should * Added recommendations/suggestion of which WG each issue should
be addressed as pointed out in 61st IETF. be addressed as pointed out in 61st IETF.
* Minor updates on references. * Minor updates on references.
o Changes from draft-ietf-nemo-multihoming-issues-00 to -01: o Changes from draft-ietf-nemo-multihoming-issues-00 to -01:
* Replaced NEMO-Prefix with MNP as decided by the WG at 60th IETF * Replaced NEMO-Prefix with MNP as decided by the WG at 60th IETF
* Addressed Issue #1 in Section 1: Added a note to remind readers * Addressed Issue #1 in Section 1: Added a note to remind readers
that IPv6 is implicitly assumed that IPv6 is implicitly assumed
* Addressed Issue #3 in Section 2.3: Removed text on assumption * Addressed Issue #3 in Section 2.3: Removed text on assumption
* Addressed Issue #6 in Section 3.1: Added benefits * Addressed Issue #6 in Section 3.1: Added benefits
* Addressed Issue #7 in Section 3.2: Modified text * Addressed Issue #7 in Section 3.2: Modified text
* Addressed Issue #9 in Section 4.3: Modified text * Addressed Issue #9 in Section 4.2: Modified text
* Addressed Issue #10 in Section 4.1.1: Added paragraph on other
* Addressed Issue #10 in Section 4.4: Added paragraph on other
failure modes failure modes
* Addressed Issue #10: New Section 4.5 on media detection * Addressed Issue #10: New Section 4.3 on media detection
* Addressed Issue #11 in Section 4.11: modified text * Addressed Issue #11 in Section 4.11: modified text
o Changes from draft-ng-multihoming-issues-03 to o Changes from draft-ng-multihoming-issues-03 to
draft-ietf-nemo-multihoming-issues-00: draft-ietf-nemo-multihoming-issues-00:
* Expanded "Problem Statement" (Section 4) * Expanded "Problem Statement" (Section 4)
* Merged "Evaluation" Section into "Problem Statement" * Merged "Evaluation" Section into "Problem Statement"
(Section 4) (Section 4)
skipping to change at page 35, line 16 skipping to change at page 40, line 35
o Changes from draft-ng-multihoming-issues-02 to o Changes from draft-ng-multihoming-issues-02 to
draft-ng-multihoming-issues-03: draft-ng-multihoming-issues-03:
* Merged with draft-eun-nemo-multihoming-problem-statement (see * Merged with draft-eun-nemo-multihoming-problem-statement (see
"Problem Statement" (Section 4)) "Problem Statement" (Section 4))
* Included conclusions from * Included conclusions from
draft-charbon-nemo-multihoming-evaluation-00 draft-charbon-nemo-multihoming-evaluation-00
* Re-organized some part of "Benefits/Issues of Multhoming in * Re-organized some part of "Benefits/Issues of Multihoming in
NEMO" to "Problem Statement" (Section 4) NEMO" to "Problem Statement" (Section 4)
* Removed lots of text to be in sync with [6]. * Removed lots of text to be in sync with [6].
* Title changed from "Multihoming Issues in NEMO Basic Support" * Title changed from "Multihoming Issues in NEMO Basic Support"
to "Analysis of Multihoming in NEMO" to "Analysis of Multihoming in NEMO"
* Changed (w,x,y) to (x,y,z) in taxonomy. * Changed (w,x,y) to (x,y,z) in taxonomy.
* Moved alternative approaches of classification to Appendix * Moved alternative approaches of classification to Appendix
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/