< draft-ietf-nemo-multihoming-issues-06.txt   draft-ietf-nemo-multihoming-issues-07.txt >
NEMO Working Group C. Ng NEMO Working Group C. Ng
Internet-Draft Panasonic Singapore Labs Internet-Draft Panasonic Singapore Labs
Expires: December 24, 2006 E. Paik Expires: August 9, 2007 T. Ernst
KT
T. Ernst
INRIA INRIA
E. Paik
KT
M. Bagnulo M. Bagnulo
UC3M UC3M
June 22, 2006 February 5, 2007
Analysis of Multihoming in Network Mobility Support Analysis of Multihoming in Network Mobility Support
draft-ietf-nemo-multihoming-issues-06 draft-ietf-nemo-multihoming-issues-07
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 December 24, 2006. This Internet-Draft will expire on August 9, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
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) in IPv6. As there are many situations in which mobility (NEMO) in IPv6. As there are many situations in which
mobile networks may be multihomed, a taxonomy is proposed to classify mobile networks may be multihomed, a taxonomy is proposed to classify
the possible configurations. The possible deployment scenarios of the possible configurations. The possible deployment scenarios of
multihomed mobile networks are described together with the associated multihomed mobile networks are described together with the associated
issues when network mobility is supported by RFC 3963 (NEMO Basic issues when network mobility is supported by RFC 3963 (NEMO Basic
Support). Recommendations are offered on how to address these Support). Recommendations are offered on how to address these
skipping to change at page 2, line 28 skipping to change at page 2, line 34
2.4. (1,n,n): Single MR, Multiple HAs, Multiple MNPs . . . . . 9 2.4. (1,n,n): Single MR, Multiple HAs, Multiple MNPs . . . . . 9
2.5. (n,1,1): Multiple MRs, Single HA, Single MNP . . . . . . . 10 2.5. (n,1,1): Multiple MRs, Single HA, Single MNP . . . . . . . 10
2.6. (n,1,n): Multiple MRs, Single HA, Multiple MNPs . . . . . 10 2.6. (n,1,n): Multiple MRs, Single HA, Multiple MNPs . . . . . 10
2.7. (n,n,1): Multiple MRs, Multiple HAs, Single MNP . . . . . 11 2.7. (n,n,1): Multiple MRs, Multiple HAs, Single MNP . . . . . 11
2.8. (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs . . . . 12 2.8. (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs . . . . 12
3. Deployment Scenarios and Prerequisites . . . . . . . . . . . . 13 3. Deployment Scenarios and Prerequisites . . . . . . . . . . . . 13
3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 13 3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 13
3.2. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 15 3.2. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 15
4. Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 16 4. Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 16 4.1. Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 17
4.1.1. Failure Detection . . . . . . . . . . . . . . . . . . 16 4.1.1. Failure Detection . . . . . . . . . . . . . . . . . . 17
4.1.2. Path Exploration . . . . . . . . . . . . . . . . . . . 18 4.1.2. Path Exploration . . . . . . . . . . . . . . . . . . . 19
4.1.3. Path Selection . . . . . . . . . . . . . . . . . . . . 19 4.1.3. Path Selection . . . . . . . . . . . . . . . . . . . . 20
4.1.4. Re-Homing . . . . . . . . . . . . . . . . . . . . . . 21 4.1.4. Re-Homing . . . . . . . . . . . . . . . . . . . . . . 22
4.2. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 21 4.2. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 22
4.3. HA Synchronization . . . . . . . . . . . . . . . . . . . . 23 4.3. HA Synchronization . . . . . . . . . . . . . . . . . . . . 24
4.4. MR Synchronization . . . . . . . . . . . . . . . . . . . . 24 4.4. MR Synchronization . . . . . . . . . . . . . . . . . . . . 24
4.5. Prefix Delegation . . . . . . . . . . . . . . . . . . . . 24 4.5. Prefix Delegation . . . . . . . . . . . . . . . . . . . . 25
4.6. Multiple Bindings/Registrations . . . . . . . . . . . . . 25 4.6. Multiple Bindings/Registrations . . . . . . . . . . . . . 26
4.7. Source Address Selection . . . . . . . . . . . . . . . . . 25 4.7. Source Address Selection . . . . . . . . . . . . . . . . . 26
4.8. Loop Prevention in Nested Mobile Networks . . . . . . . . 26 4.8. Loop Prevention in Nested Mobile Networks . . . . . . . . 26
4.9. Prefix Ownership . . . . . . . . . . . . . . . . . . . . . 26 4.9. Prefix Ownership . . . . . . . . . . . . . . . . . . . . . 27
4.10. Preference Settings . . . . . . . . . . . . . . . . . . . 26 4.10. Preference Settings . . . . . . . . . . . . . . . . . . . 27
5. Recommendations to the Working Group . . . . . . . . . . . . . 28 5. Recommendations to the Working Group . . . . . . . . . . . . . 29
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 31 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
10.1. Normative References . . . . . . . . . . . . . . . . . . . 32 10.1. Normative References . . . . . . . . . . . . . . . . . . . 33
10.2. Informative References . . . . . . . . . . . . . . . . . . 32 10.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Alternative Classifications Approach . . . . . . . . 35 Appendix A. Alternative Classifications Approach . . . . . . . . 36
A.1. Ownership-Oriented Approach . . . . . . . . . . . . . . . 35 A.1. Ownership-Oriented Approach . . . . . . . . . . . . . . . 36
A.1.1. ISP Model . . . . . . . . . . . . . . . . . . . . . . 35 A.1.1. ISP Model . . . . . . . . . . . . . . . . . . . . . . 36
A.1.2. Subscriber/Provider Model . . . . . . . . . . . . . . 36 A.1.2. Subscriber/Provider Model . . . . . . . . . . . . . . 37
A.2. Problem-Oriented Approach . . . . . . . . . . . . . . . . 38 A.2. Problem-Oriented Approach . . . . . . . . . . . . . . . . 39
Appendix B. Nested Tunneling for Fault Tolerance . . . . . . . . 39 Appendix B. Nested Tunneling for Fault Tolerance . . . . . . . . 40
B.1. Detecting Presence of Alternate Routes . . . . . . . . . . 39 B.1. Detecting Presence of Alternate Routes . . . . . . . . . . 40
B.2. Re-Establishment of Bi-Directional Tunnels . . . . . . . . 40 B.2. Re-Establishment of Bi-Directional Tunnels . . . . . . . . 41
B.2.1. Using Alternate Egress Interface . . . . . . . . . . . 40 B.2.1. Using Alternate Egress Interface . . . . . . . . . . . 41
B.2.2. Using Alternate Mobile Router . . . . . . . . . . . . 40 B.2.2. Using Alternate Mobile Router . . . . . . . . . . . . 41
B.3. To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . 41 B.3. To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . 42
B.4. Points of Considerations . . . . . . . . . . . . . . . . . 41 B.4. Points of Considerations . . . . . . . . . . . . . . . . . 42
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 42 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . . . . . 46 Intellectual Property and Copyright Statements . . . . . . . . . . 48
1. Introduction 1. Introduction
The design goals and objectives of Network Mobility Support (NEMO) in The design goals and objectives of Network Mobility Support (NEMO) in
IPv6 are identified in [1] while the terminology is being described IPv6 are identified in [1] while the terminology is being described
in [2] and [3]. NEMO Basic Support (RFC 3963) [4] is the solution in [2] and [3]. NEMO Basic Support (RFC 3963) [4] is the solution
proposed by the NEMO Working Group to provide continuous Internet proposed by the NEMO Working Group to provide continuous Internet
connectivity to nodes located in an IPv6 mobile network, e.g. like in connectivity to nodes located in an IPv6 mobile network, e.g. like in
an in-vehicle embedded IP network. The NEMO Basic Support solution an in-vehicle embedded IP network. The NEMO Basic Support solution
basically solves the problem by setting up bi-directional tunnels does so by setting up bi-directional tunnels between the mobile
between the mobile routers (MRs) connecting the mobile network to the routers (MRs) connecting the mobile network to the Internet and their
Internet and their respective Home Agents (HAs), much how this is respective home agents (HAs), much like how this is done in Mobile
done in Mobile IPv6 [5], the solution for host mobility support. IPv6 [5], the solution for host mobility support. NEMO Basic Support
NEMO Basic Support is transparent to nodes located behind the mobile is transparent to nodes located behind the mobile router (i.e. the
router (i.e. the mobile network nodes, or MNNs) and as such does not mobile network nodes, or MNNs) and as such does not require MNNs to
require MNNs to take any action in the mobility management. 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 mobile Internet has thus a more significant impact than for a single mobile
node. Scenarios illustrated in [6] demonstrate that providing a node. Scenarios illustrated in [6] demonstrate that providing 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 in section 5 of the NEMO Basic Support Requirements [1]
that NEMO Basic Support does not prevent mobile networks to be (R.12), the NEMO WG must ensure that NEMO Basic Support does not
multihomed, i.e. when there is more than one point of attachment prevent mobile networks to be multihomed, i.e. when there is more
between the mobile network and the Internet (see definitions in [3]). than one point of attachment between the mobile network and the
This arises either: Internet (see definitions in [3]). This arises either:
o when a MR has multiple egress interfaces, or o when a MR has multiple egress interfaces, or
o the mobile network has multiple MRs, or o the mobile network has multiple MRs, or
o the mobile network is associated with multiple HAs, or o the mobile network is associated with multiple HAs, or
o multiple global prefixes are available in the mobile network. o multiple global prefixes are available in the mobile network.-->
Using NEMO Basic Support, this would translate into having multiple Using NEMO Basic Support, this would translate into having multiple
bi-directional tunnels between the MR(s) and the corresponding HA, bi-directional tunnels between the MR(s) and the corresponding HA,
and may result into multiple MNPs available to the MNNs. However, 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 objectives of this memo
is thus multi-folded: are thus multifold:
o to determine all the potential multihomed configurations for a o to determine all the potential multihomed configurations for a
NEMO, and then to identify which of those may be useful in a real NEMO, and then to identify which of these may be useful in a real
life scenario; life scenario;
o to capture issues that may prevent some multihomed configurations o to capture issues that may prevent some multihomed configurations
to be supported under the operation of NEMO Basic Support. It to be supported under the operation of NEMO Basic Support. It
doesn't necessarily mean that those not supported will not work doesn't necessarily mean that the ones not supported will not work
with NEMO Basic Support, as it may be up to the implementors to with NEMO Basic Support, as it may be up to the implementors to
make it work (hopefully this memo will be helpful to these make it work (hopefully this memo will be helpful to these
implementors); implementors);
o to identify potential solutions to the previously identified o to decide which issues are worth solving and to determine which WG
issues; and is the most appropriate to address these;
o to decide which issues are worth to be solved, and to determine o to identify potential solutions to the previously identified
which WG should address each of the issues that are worth solving. issues.
In order to reach these objectives, a taxonomy to classify the In order to reach these objectives, a taxonomy for classifying the
possible multihomed configurations is described in Section 2. possible multihomed configurations is described in Section 2.
Deployment scenarios, their benefits, and requirements to meet these Deployment scenarios, their benefits, and requirements to meet these
benefits are illustrated in Section 3. Following this, the related benefits are illustrated in Section 3. Following this, the related
issues are studied in Section 4. The issues are then summarized in a issues are studied in Section 4. The issues are then summarized in a
matrix for each of the deployment scenario, and recommendations are matrix for each of the deployment scenario, and recommendations are
made on which of the issues should be worked on and where in made on which of the issues should be worked on and where in
Section 5. This memo concludes with an evaluation of NEMO Basic Section 5. This memo concludes with an evaluation of NEMO Basic
Support for multihomed configurations. Alternative classifications Support for multihomed configurations. Alternative classifications
are outlined in the Appendix. are outlined in the Appendix.
The readers should note that this document considers multihoming only The readers should note that this document considers multihoming only
from the point of view of an IPv6 environment. In order to from the point of view of an IPv6 environment. In order to
understand this memo, the reader is expected to be familiar with the understand this memo, the reader is expected to be familiar with the
above cited documents, i.e. with the NEMO terminology as defined in above cited documents, i.e. with the NEMO terminology as defined in
[2] (section 3) and [3], Motivations and and Scenarios for [2] (section 3) and [3], Motivations and Scenarios for Multihoming
Multihoming [6], Goals and Requirements of Network Mobility Support [6], Goals and Requirements of Network Mobility Support [1], and the
[1], and the NEMO Basic Support specification [4]. Goals and NEMO Basic Support specification [4]. Goals and benefits of
benefits of multihoming as discussed in [6] are applicable to fixed multihoming as discussed in [6] are applicable to fixed nodes, mobile
nodes, mobile nodes, fixed networks and mobile networks. nodes, fixed networks and mobile networks.
2. Classification 2. Classification
As there are several configurations in which mobile networks are As there are several configurations in which mobile networks are
multihomed, there is a need to classify them into a clearly defined multihomed, there is a need to classify them into a clearly defined
taxonomy. This can be done in various ways. A Configuration- taxonomy. This can be done in various ways. A Configuration-
Oriented taxonomy is described in this section. Two other Oriented taxonomy is described in this section. Two other
taxonomies, namely, the Ownership-Oriented Approach, and the Problem- taxonomies, namely, the Ownership-Oriented Approach, and the Problem-
Oriented Approach are outlined in Appendix A.1 and Appendix A.2. Oriented Approach are outlined in Appendix A.1 and Appendix A.2.
skipping to change at page 6, line 25 skipping to change at page 6, line 25
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 available to the mobile network nodes, etc. many prefixes (MNPs) are available to the mobile network nodes, etc.
We use three key parameters to differentiate the multihomed We use three key parameters to differentiate the multihomed
configurations. Using these parameters, each configuration is configurations. Using these parameters, each configuration is
referred by the 3-tuple (x,y,z), where 'x', 'y', 'z' are defined as referred by the 3-tuple (x,y,z), where 'x', 'y', 'z' are 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 that a mobile network has only a single MR,
multihomed. presumably multihomed.
x=n implies a mobile network has more than one MR. x=n implies that 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 are assigned to the mobile network. y=n implies that multiple HAs are assigned to the mobile network.
o 'z' indicates the number of MNPs available within the NEMO, where: o 'z' indicates the number of MNPs available within the NEMO, where:
z=1 implies that a single MNP is available in the NEMO. z=1 implies that a single MNP is available in the NEMO.
z=N implies that multiple MNPs are available in the NEMO 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' result with one another. Thus different values of 'x', 'y' and 'z' result
into different combinations of the 3-tuple (x,y,z). into different combinations of the 3-tuple (x,y,z).
As described in the sub-sections below, a total of 8 possible As described in the sub-sections below, a total of 8 possible
configurations can be identified. One thing the reader has to keep 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 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 multihomed if either (i) multiple prefixes are available (on the home
link, or on the visited link), or (ii) the MR is equipped with link, or on the foreign link), or (ii) the MR is equipped with
multiple interfaces. In such a case, the MR would have multiple HoA- multiple interfaces. In such a case, the MR would have multiple HoA-
CoA pairs. Issues pertaining to a multihomed MR are also addressed CoA pairs. Issues pertaining to a multihomed MR are also addressed
in [7]. In addition, the readers should also keep in mind that when in [7].
"MNP(s) is/are available in the NEMO", the MNP(s) may either be
explicitly announced by the MR via router advertisement, or made In addition, the readers should also keep in mind that when "MNP(s)
available through Dynamic Host Configuration Protocol (DHCP). is/are available in the NEMO", the MNP(s) may either be explicitly
announced by the MR via router advertisement, or made 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) configuration has only one MR, it is associated with a The (1,1,1) configuration has only one MR, it is associated with a
single HA, and a single MNP is available in the NEMO. To fall into a single HA, and a single MNP is available in the NEMO. To fall into a
multihomed configuration, at least one of the following conditions multihomed configuration, at least one of the following conditions
must hold: must hold:
o The MR has multiple interfaces and thus its has multiple CoAs; o The MR has multiple interfaces and thus it has multiple CoAs;
o Multiple global prefixes are available on the visited link, and o Multiple global prefixes are available on the foreign link, and
thus it has multiple CoAs; or thus it has multiple CoAs; or
o Multiple global prefixes are available on the home link, and thus
the MR has more than one path to reach the home agent.
Note that the case where multiple prefixes are available on the Note that the case where multiple prefixes are available on the
visited link does not have any bearing on the MNPs. MNPs are foreign link does not have any bearing on the MNPs. MNPs are
independent of prefixes available on the link where MR is attached, independent of prefixes available on the link where the MR is
thus prefixes available on the foreign link are not announced on the attached to, thus prefixes available on the foreign link are not
NEMO link. For the case where multiple prefixes are available on the announced on the NEMO link. For the case where multiple prefixes are
home link, these are only announced on the NEMO link if the MR is available on the home link, these are only announced on the NEMO link
configured to do so. In this configuration, only one MNP is if the MR is configured to do so. In this configuration, only one
announced. MNP is announced.
A bi-directional tunnel would then be established between each HoA- A bi-directional tunnel would then be established between each {HA
CoA pair. address,CoA} pair.
Regarding MNNs, they are (usually) not multihomed since they would Regarding MNNs, they are (usually) not multihomed since they would
configure a single global address from the single MNP available on 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) configuration has only one MR, it is associated with a The (1,1,n) configuration has only one MR, it is associated with a
single HA and two or more MNPs are available in the NEMO. single HA and two or more MNPs are available in the NEMO.
The MR may itself be multihomed, as detailed in Section 2.1. In such The MR may itself be multihomed, as detailed in Section 2.1. A bi-
a case, a bi-directional tunnel would be established between each directional tunnel would be established between each {HA address,CoA}
HoA-CoA pair. pair.
Regarding MNNs, they are multihomed because several MNPs are Regarding MNNs, they are multihomed because several MNPs are
available on the link they are attached to. The MNNs would then available on the link they are attached to. The MNNs would then
configure a global address with each MNP available on the link. configure a global address from 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) configuration has only one MR and a single MNP is The (1,n,1) configuration has only one MR and a single MNP is
available in the NEMO. The MR, however, is associated with multiple available in the NEMO. The MR, however, is associated with multiple
HAs, possibly one HA per HoA, or one HA per egress interface. HAs.
The NEMO is multihomed since it has multiple HAs, but in addition the The NEMO is multihomed since it has multiple HAs, but in addition the
conditions detailed in Section 2.1 may also hold for the MR. A bi- conditions detailed in Section 2.1 may also hold for the MR. A bi-
directional tunnel would then be established between each HoA-CoA directional tunnel would be established between each {HA address,CoA}
pair. pair.
Regarding MNNs, they are (usually) not multihomed since they would Regarding MNNs, they are (usually) not multihomed since they would
configure a single global address from the single MNP available on configure a single global address from the single MNP available on
the link they are attached to. 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) configuration has only one MR. However, the MR is The (1,n,n) configuration has only one MR. However, the MR is
associated with multiple HAs, possibly one per Home Address (or one associated with multiple HAs and more than one MNP is available in
HA per egress interface), and more than one MNP is available in the the NEMO.
NEMO.
The MR is multihomed since it has multiple HAs, but in addition the The MR is multihomed since it has multiple HAs, but in addition the
conditions detailed in Section 2.1 may also hold. A bi-directional conditions detailed in Section 2.1 may also hold. A bi-directional
tunnel would then be established between each HoA-CoA pair. tunnel would be established between each {HA address,CoA} pair.
Regarding MNNs, they are generally multihomed since they would Regarding MNNs, they are multihomed because several MNPs are
configure a global address from each MNP available on the link they available on the link they are attached to. The MNNs would then
are attached to. configure a global address with each MNP available on the link.
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) configuration has more than one MR advertising global The (n,1,1) configuration has more than one MR advertising global
routes. However, the MR(s) are associated with as single HA, and routes. However, the MR(s) are associated with as single HA, and
there in a single MNP available in the NEMO. there in a single MNP available in the NEMO.
The NEMO is multihomed since it has multiple MRs, but in addition the The NEMO is multihomed since it has multiple MRs, but in addition the
conditions detailed in Section 2.1 may also hold for each MR. A bi- conditions detailed in Section 2.1 may also hold for each MR. A bi-
directional tunnel would then be established between each HoA-CoA directional tunnel would be established between each {HA address,CoA}
pair. pair.
Regarding MNNs, they are (usually) not multihomed since they would Regarding MNNs, they are (usually) not multihomed since they would
configure a single global address from the single MNP available on configure a single global address from the single MNP available on
the link they are attached to. 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) configuration has more than one MR; multiple global The (n,1,n) configuration has more than one MR; multiple global
routes are advertised by the MRs and multiple MNPs are available routes are advertised by the MRs and multiple MNPs are available
within the NEMO. within the NEMO.
The NEMO is multihomed since it has multiple MRs, but in addition the The NEMO is multihomed since it has multiple MRs, but in addition the
conditions detailed in Section 2.1 may also hold for each MR. A bi- conditions detailed in Section 2.1 may also hold for each MR. A bi-
directional tunnel would then be established between each HoA-CoA directional tunnel would be established between each {HA address,CoA}
pair. pair.
Regarding MNNs, they are generally multihomed since they would Regarding MNNs, they are multihomed because several MNPs are
configure a global address from each MNP available on the link they available on the link they are attached to. The MNNs would then
are attached to. configure a global address with each MNP available on the link.
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) configuration has more than one MR advertising multiple The (n,n,1) configuration has more than one MR advertising multiple
global routes. The mobile network is simultaneously associated with global routes. The mobile network is simultaneously associated with
multiple HAs and a single MNP is available in the NEMO. multiple HAs and a single MNP is available in the NEMO.
The NEMO is multihomed since it has multiple MRs and HAs, but in The NEMO is multihomed since it has multiple MRs and HAs, but in
addition the conditions detailed in Section 2.1 may also hold for addition the conditions detailed in Section 2.1 may also hold for
each MR. A bi-directional tunnel would then be established between each MR. A bi-directional tunnel would be established between each
each HoA-CoA pair. {HA address,CoA} pair.
Regarding MNNs, they are (usually) not multihomed since they would Regarding MNNs, they are (usually) not multihomed since they would
configure a single global address from the single MNP available on configure a single global address from the single MNP available on
the link they are attached to. 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) configuration has multiple MRs advertising different The (n,n,n) configuration has multiple MRs advertising different
global routes. The mobile network is simultaneously associated with global routes. The mobile network is simultaneously associated with
more than one HA and multiple MNPs are available in the NEMO. more than one HA and multiple MNPs are available in the NEMO.
The NEMO is multihomed since it has multiple MRs and HAs, but in The NEMO is multihomed since it has multiple MRs and HAs, but in
addition the conditions detailed in Section 2.1 may also hold for addition the conditions detailed in Section 2.1 may also hold for
each MR. A bi-directional tunnel would then be established between each MR. A bi-directional tunnel would be established between each
each HoA-CoA pair. {HA address,CoA} pair.
Regarding MNNs, they are generally multihomed since they would Regarding MNNs, they are multihomed because several MNPs are
configure a global address from each MNP available on the link they available on the link they are attached to. The MNNs would then
are attached to. configure a global address with each MNP available on the link.
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 [6]: in [6]:
1. Permanent and Ubiquitous Access 1. Permanent and Ubiquitous Access
2. Reliability 2. Reliability
skipping to change at page 13, line 30 skipping to change at page 13, line 30
6. Aggregate Bandwidth 6. Aggregate Bandwidth
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 networks 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 1:
802.11 and GPRS capabilities). This is a (1,1,*) if both
accesses are subscribed to the same ISP. If the two accesses MR with dual/multiple access interfaces (e.g. 802.11 and GPRS
are offered by independent ISPs, this is a (1,n,n) capabilities). This is a (1,1,*) if both accesses are
performed with the same ISP. If the two accesses are offered
by independent ISPs, this is a (1,n,n) configuration.
Benefits: Ubiquitous Access, Reliability, Load Sharing, Benefits: Ubiquitous Access, Reliability, Load Sharing,
Preference Settings, Aggregate Bandwidth Preference Settings, Aggregate Bandwidth.
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:
same HA, thus a (n,1,*) configuration. Alternatively, the
train company might be forced to use different ISPs when the
train go to different locations, thus it is a (n,n,n)
configuration.
Benefits: Load Sharing, Reliability, Ubiquitous Access, Train with one MR in each car, all served by the same HA, thus
Aggregate Bandwidth a (n,1,*) configuration. Alternatively, the train company
might be forced to use different ISPs when the train crosses
different countries, thus a (n,n,n) configuration.
o Example 2: W-PAN with a GPRS-enabled phone and a WiFi-enabled Benefits: Ubiquitous Access, Reliability, Load Sharing,
PDA. This is a (n,n,n) configuration if the two access Aggregate Bandwidth.
technologies are subscribed separately.
o Example 2:
W-PAN with a GPRS-enabled phone and a WiFi-enabled PDA. This
is a (n,n,n) configuration if the two access technologies are
subscribed separately.
Benefits: Ubiquitous Access, Reliability, Preference Settings, Benefits: Ubiquitous Access, Reliability, Preference Settings,
Aggregate Bandwidth Aggregate Bandwidth.
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 Example:
y=N: Multihomed mobile networks with multiple HAs Most single ISP cases in above examples.
o Most multiple ISP cases in above examples. y=N: Multihomed mobile networks with multiple HAs
o Example: a transatlantic flight with a HA in each continent. o Example 1:
This is a (1,n,1) configuration if there is only one MR.
Benefits: Ubiquity, Preferences (reduced delay, shortest path), Most multiple ISP cases in above examples.
Reliability
z=1: Multihomed mobile networks with a single MNP o Example 2:
o Most single ISP cases in above examples. Transatlantic flight with a HA in each continent. This is a
(1,n,1) configuration if there is only one MR.
z=N: Multihomed mobile networks with multiple MNPs Benefits: Ubiquitous Access, Reliability, Preference Settings
(reduced delay, shortest path).
o Most multiple ISP cases in above examples. z=1: Multihomed mobile networks with a single MNP
o Example: a car with a prefix taken from home (personal traffic o Example:
transit on this prefix and is paid by the owner) and one that
belongs to the car manufacturer (maintenance traffic is paid by Most single ISP cases in above examples.
the car manufacturer). This will typically be a (1,1,n) or a
(1,n,n,) configuration. z=N: Multihomed mobile networks with multiple MNPs
o Example 1:
Most multiple ISP cases in above examples.
o Example 2:
Car with a prefix taken from home (personal traffic is
transmitted using this prefix and is paid by the owner) and one
that belongs to the car manufacturer (maintenance traffic is
paid by the car manufacturer). This will typically be a
(1,1,n) or a (1,n,n,) configuration.
Benefits: Preference Settings Benefits: Preference Settings
3.2. Prerequisites 3.2. Prerequisites
In this section, requirements are started in order to comply with the In this section, requirements are stated in order to comply with the
expected benefits of multihoming 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
skipping to change at page 15, line 42 skipping to change at page 16, line 12
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 bi- preferences are set for deciding which of the available bi-
directional tunnels should be used. To allow user/application to directional tunnels should be used. To allow user/application to
set the preference, a mechanism should be provided to the user/ set the preference, a mechanism should be provided to the user/
application for the notification of the availability of multiple application for the notification of the availability of multiple
bi-directional tunnels, and perhaps also to set preferences. bi-directional tunnels, and perhaps also to set preferences.
Similar mechanism should also be provided to network Similar mechanism should also be provided to network
administrators for the administration of the preferences. administrators to manage preferences.
o Aggregate Bandwidth: o Aggregate Bandwidth:
Multiple tunnels must be maintained simultaneously in order to Multiple tunnels must be maintained simultaneously in order to
increase the total aggregated bandwidth available to the mobile increase the total aggregated bandwidth available to the mobile
network. network.
4. Multihoming Issues 4. Multihoming Issues
As discussed in the previous section, multiple bi-directional tunnels As discussed in the previous section, multiple bi-directional tunnels
need to be maintained either sequentially (e.g. for fault tolerance) need to be maintained either sequentially (e.g. for fault tolerance)
or simultaneously (e.g. for load sharing). or simultaneously (e.g. for load sharing).
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 tunnels recovery, preferences), or to split traffic between multiple tunnels
(load sharing, load balancing). (load sharing, load balancing).
So, depending on the configuration under consideration, the issues So, depending on the configuration under consideration, the issues
discussed below may need to be addressed, sometimes dynamically. For discussed below may need to be addressed sometimes dynamically. For
each issue, potential ways to solve the problem are investigated. each issue, potential ways to solve the problem are investigated.
4.1. Fault Tolerance 4.1. Fault Tolerance
One of the goals of multihoming is the provision of fault tolerance One of the goals of multihoming is the provision of fault tolerance
capabilities. In order to provide such features, a set of tasks need capabilities. In order to provide such features, a set of tasks need
to be performed, including: failure detection, alternative available to be performed, including: failure detection, alternative available
path exploration, path selection, re-homing of established path exploration, path selection, re-homing of established
communications. These are also discussed in [8] and [9] by the Shim6 communications. These are also discussed in [8] and [8] by the Shim6
WG. In the following sub-sections, we look at these issues in the WG. In the following sub-sections, we look at these issues in the
specific context of NEMO, rather than the general Shim6 perspective specific context of NEMO, rather than the general Shim6 perspective
in [8] [9]. In addition, in some scenarios, it may also be required in [8]. In addition, in some scenarios, it may also be required to
to provide the mechanisms for coordination between different HAs (see provide the mechanisms for coordination between different HAs (see
Section 4.3) and also the coordination between different MRs (see Section 4.3) and also the coordination between different MRs (see
Section 4.4). Section 4.4).
4.1.1. Failure Detection 4.1.1. Failure Detection
It is expected for faults to occur more readily at the edge of the 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 network (i.e. the mobile nodes), due to the use of wireless
connections. Efficient fault detection mechanisms are necessary to connections. Efficient fault detection mechanisms are necessary to
recover in timely fashion. Depending on the NEMO configuration recover in timely fashion.
considered, the failure protection domain greatly varies. In some
configurations, the protection domain provided by NEMO multihoming is Depending on the NEMO configuration considered, the failure
limited to the links between the MR(s) and the HA(s). In other protection domain greatly varies. In some configurations, the
configurations, the protection domain allows to recover from failures protection domain provided by NEMO multihoming is limited to the
in other parts of the path, so an end to end failure detection links between the MR(s) and the HA(s). In other configurations, the
mechanism is required. protection domain allows to recover from failures in other parts of
the path, so an end to end failure detection mechanism is required.
Below are detailed which failure detection capabilities are required Below are detailed which failure detection capabilities are required
for each configuration: for each configuration:
o For the (1,1,*) cases, multiple paths are available between a 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 single MR and a single HA. All the traffic from and to the NEMO
flows through these MR and HA. Failure detection mechanisms need flows through these MR and HA. Failure detection mechanisms need
only to be executed between these two devices. This is a NEMO/ only to be executed between these two devices. This is a NEMO/
MIPv6 specific issue. MIPv6 specific issue.
skipping to change at page 17, line 25 skipping to change at page 18, line 28
o For the (n,n,*) cases, there are multiple paths between the o For the (n,n,*) cases, there are multiple paths between the
different HAs and the different MRs. Moreover, the HAs may be different HAs and the different MRs. Moreover, the HAs may be
located in different networks, and have different Internet access located in different networks, and have different Internet access
links. This implies that changing the HA used may not only allow links. This implies that changing the HA used may not only allow
recovering from failures in the link between the HA and the MR, recovering from failures in the link between the HA and the MR,
but also from other failure modes, affecting other parts of the but also from other failure modes, affecting other parts of the
path. In this case, an end-to-end failure detection mechanism path. In this case, an end-to-end failure detection mechanism
would provide additional protection. However, a higher number of would provide additional protection. However, a higher number of
failures is likely to occur in the link between the HA and the MR, failures is likely to occur in the link between the HA and the MR,
so it may be reasonable to provide optimized failure detection so it may be reasonable to provide optimized failure detection
mechanisms for this failure mode. The (n,n,1) case, however, mechanisms for this failure mode. The (n,n,n) case is hybrid,
seems to be pretty NEMO specific, because of the absence of since selecting a different prefix results in a change of path.
multiple prefixes. The (n,n,n) case is hybrid, since for those For this case the Shim6 protocols (such as those discussed in [8])
cases when selecting a different prefix results in a change of may be useful.
path, the Shim6 protocols (such as those discussed in [8]) may be
useful. The other cases are NEMO specific.
Most of the above cases involve the detection of tunnel failures Most of the above cases involve the detection of tunnel failures
between HA(s) and MR(s). This is no different from the case of between HA(s) and MR(s). This is no different from the case of
failure detection between a mobile host and its HA(s). As such, a failure detection between a mobile host and its HA(s). As such, a
solution for MIPv6 should apply to NEMO as well. For the case of solution for MIPv6 should apply to NEMO as well. For case (n,*,*), a
(n,*,*), a MR synchronization solution (see Section 4.4) should be MR synchronization solution (see Section 4.4) should be able to
able to compliment a MIPv6 failure detection solution to achieve the complement a MIPv6 failure detection solution to achieve the desired
desired functionality for NEMO. functionality for NEMO.
In order for fault recovery to work, the MRs and HAs must first In order for fault recovery to work, the MRs and HAs must first
possess a means to detect failures: possess a means to detect failures:
o On the MR's side, the MR can rely on router advertisements from o On the MR's side, the MR can rely on router advertisements from
access routers, or other layer-2 trigger mechanisms to detect access routers, or other layer-2 trigger mechanisms to detect
faults, e.g. [10], [11], [12] or [13]. faults, e.g. [9] and [10].
o On the HA's side, it is more difficult to detect tunnel failures. 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 For an ISP deployment model, the HAs and MRs can use proprietary
methods (such as constant transmission of heartbeat signals) to methods (such as constant transmission of heartbeat signals) to
detect failures and check tunnel liveness. In the subscriber detect failures and check tunnel liveness. In the subscriber
model (see Appendix A.2: S/P model), a lack of standardized model (see Appendix A.2: S/P model), a lack of standardized
"tunnel liveness" protocol means that it is harder to detect "tunnel liveness" protocol means that it is harder to detect
failures. failures.
A possible method is for the MRs to send binding updates more A possible method is for the MRs to send binding updates more
skipping to change at page 18, line 19 skipping to change at page 19, line 19
binding acknowledgment messages with smaller Lifetime values, thus binding acknowledgment messages with smaller Lifetime values, thus
forcing the MRs to send binding updates more frequently. These forcing the MRs to send binding updates more frequently. These
binding updates can be used to emulate "tunnel heartbeats". This binding updates can be used to emulate "tunnel heartbeats". This
however may lead to more traffic and processing overhead, since however may lead to more traffic and processing overhead, since
binding updates sent to HAs must be protected (and possibly binding updates sent to HAs must be protected (and possibly
encrypted) with security associations. encrypted) with security associations.
4.1.2. Path Exploration 4.1.2. Path Exploration
Once a failure in the currently used path is detected, alternative Once a failure in the currently used path is detected, alternative
paths need to be explored in order to identify an available one. paths have to be explored in order to identify an available one.
This process is closely related to failure detection in the sense This process is closely related to failure detection in the sense
that paths being explored need to be alternative paths to the one that paths being explored need to be alternative paths to the one
that has failed. There are, however, subtle but significant that has failed. There are, however, subtle but significant
differences between path exploration and failure detection. Failure differences between path exploration and failure detection. Failure
detection occurs on the currently used path while path exploration detection occurs on the currently used path while path exploration
occurs on the alternative paths (not on the one currently being used occurs on the alternative paths (not on the one currently being used
for exchanging packets). Although both path exploration and failure for exchanging packets). Although both path exploration and failure
detection are likely to rely on a reachability or keepalive test detection are likely to rely on a reachability or keepalive test
exchange, failure detection also relies on other information, such as exchange, failure detection also relies on other information, such as
upper layer information (e.g. positive or negative feedback form upper layer information (e.g. positive or negative feedback form
TCP), lower layer information (e.g. an interface is down), and TCP), lower layer information (e.g. an interface is down), and
network layer information (e.g. as an address being deprecated or network layer information (e.g. as an address being deprecated or
ICMP error message). ICMP error message).
Basically, the same cases as in the analysis of the failure detection Basically, the same cases as in the analysis of the failure detection
(Section 4.1.1) issue are identified: (Section 4.1.1) issue are identified:
o For the (1,1,*) cases, multiple paths are available between a 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 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 the MR have to be explored to identify an available one. The
mechanism involves only the HA and the MR. This is a NEMO/MIPv6 mechanism involves only the HA and the MR. This is a NEMO/MIPv6
specific issue. specific issue.
o For the (n,1,*) cases, there is a single HA, so all the traffic 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 from and to the NEMO will flow through it. The available
alternative paths are the different ones between the different MRs alternative paths are the different ones between the different MRs
and the HA. The path exploration mechanism needs only to involve and the HA. The path exploration mechanism only involves the HA
the HA and the MRs. This is a NEMO/MIPv6 specific issue. and the MRs. This is a NEMO/MIPv6 specific issue.
o For the (n,n,*) cases, there are multiple paths between the o For the (n,n,*) cases, there are multiple paths between the
different HAs and the different MRs. In this case, alternative different HAs and the different MRs. In this case, alternative
paths may be routed completely independently one from one another. paths may be routed completely independently one from one another.
An end-to-end path exploration mechanism would be able to discover An end-to-end path exploration mechanism would be able to discover
if any of the end-to-end paths is available. The (n,n,1) case, if any of the end-to-end paths is available. The (n,n,1) case,
however, seems to be pretty NEMO specific, because of the absence however, seems to be pretty NEMO specific, because of the absence
of multiple prefixes. The (n,n,n) case is hybrid, since for those of multiple prefixes. The (n,n,n) case is hybrid, since selecting
cases that selecting a different prefix result in a change of a different prefix results in a change of path. For this case the
path, the Shim6 protocols (such as [9]) may be useful. The other Shim6 protocols (such as those discussed in [8]) may be useful.
cases, are NEMO specific.
Most of the above cases involve the path exploration of tunnels Most of the above cases involve the path exploration of tunnels
between HA(s) and MR(s). This is no different from the case of path between HA(s) and MR(s). This is no different from the case of path
exploration between a mobile host and its HA(s). As such, a solution exploration between a mobile host and its HA(s). As such, a solution
for MIPv6 should apply to NEMO as well. For the case of (n,*,*), a for MIPv6 should apply to NEMO as well. For case (n,*,*), a MR
MR synchronization solution (see Section 4.4) should be able to synchronization solution (see Section 4.4) should be able to
compliment a MIPv6 path exploration solution to achieve the desired compliment a MIPv6 path exploration solution to achieve the desired
functionality for NEMO. functionality for NEMO.
In order to perform path exploration, it is sometimes also necessary In order to perform path exploration, it is sometimes also necessary
for the mobile router to detect the availability of network media. for the mobile router to detect the availability of network media.
This may be achieved using layer 2 triggers [10], or other mechanism This may be achieved using layer 2 triggers [9], or other mechanism
developed/recommended by the Detecting Network Attachment (DNA) developed/recommended by the Detecting Network Attachment (DNA)
Working Group [11][14]. This is related to Section 4.1.1, since the Working Group [10]. This is related to Section 4.1.1, since the
ability to detect media availability would often implies the ability ability to detect media availability would often implies the ability
to detect media un-availability. to detect media un-availability.
4.1.3. Path Selection 4.1.3. Path Selection
A path selection mechanism is required to select among the multiple A path selection mechanism is required to select among the multiple
available paths. Depending on the NEMO multihoming configuration available paths. Depending on the NEMO multihoming configuration
involved, the differences between the paths may affect only the part involved, the differences between the paths may affect only the part
between the HA and the MR, or they may affect the full end-to-end between the HA and the MR, or they may affect the full end-to-end
path. In addition, depending on the configuration, path selection path. In addition, depending on the configuration, path selection
skipping to change at page 20, line 20 skipping to change at page 21, line 19
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.
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]
[15]) in the (n,*,*) case or based on "Source Address Selection" [11]) in the (n,*,*) case or based on "Source Address Selection"
in the (*,*,n) cases (see Section 4.7 of the present memo). in the (*,*,n) cases (see Section 4.7 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 e.g. 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.
When multiple bi-directional tunnels are available and possibly used When multiple bi-directional tunnels are available and possibly used
simultaneously, the mode of operation may be either primary-secondary simultaneously, the mode of operation may be either primary-secondary
(one tunnel is precedent over the others and used as the default (one tunnel is precedent over the others and used as the default
tunnel, while the other serves as a back-up) or peer-to-peer (no 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 tunnel has precedence over one another, they are used with the same
skipping to change at page 21, line 4 skipping to change at page 21, line 51
For (1,*,*) cases, they are no different from the case of path For (1,*,*) cases, they are no different from the case of path
selection between a mobile host and its HA(s). As such, a solution selection between a mobile host and its HA(s). As such, a solution
for MIPv6 should apply to NEMO as well. For the (n,*,*) cases, a MR for MIPv6 should apply to NEMO as well. For the (n,*,*) cases, a MR
synchronization solution (see Section 4.4) should be able to synchronization solution (see Section 4.4) should be able to
compliment a MIPv6 path selection solution to achieve the desired compliment a MIPv6 path selection solution to achieve the desired
functionality for NEMO. functionality for NEMO.
The mechanisms for selecting among different end-to-end paths based The mechanisms for selecting among different end-to-end paths based
on address selection are similar to the ones used in other on address selection are similar to the ones used in other
multihoming scenarios, as those considered by Shim6 (e.g. [16]). multihoming scenarios, as those considered by Shim6 (e.g. [12]).
4.1.4. Re-Homing 4.1.4. Re-Homing
After an outage has been detected and an available alternative path After an outage has been detected and an available alternative path
has been identified, a re-homing event takes place, diverting the has been identified, a re-homing event takes place, diverting the
existing communications from one path to the other. Similar to the existing communications from one path to the other. Similar to the
previous items involved in this process, the re-homing procedure previous items involved in this process, the re-homing procedure
heavily varies depending on the NEMO multihoming configuration. heavily varies depending on the NEMO multihoming configuration.
o For the (*,*,1) configurations, the re-homing procedure involves o For the (*,*,1) configurations, the re-homing procedure involves
only the MR(s) and the HA(s). The re-homing procedure may involve only the MR(s) and the HA(s). The re-homing procedure may involve
the exchange of additional BU messages. These mechanisms are the exchange of additional BU messages. These mechanisms are
shared between NEMO Basic Support and MIPv6. shared between NEMO Basic Support and MIPv6.
o For the (*,*,n) cases, in addition to the previous mechanisms, end o For the (*,*,n) cases, in addition to the previous mechanisms, end
to end mechanisms may be required. Such mechanisms may involve to end mechanisms may be required. Such mechanisms may involve
some form of end to end signaling or may simply rely on using some form of end to end signaling or may simply rely on using
different addresses for the communication. The involved different addresses for the communication. The involved
mechanisms may be similar to those required for re-homing Shim6 mechanisms may be similar to those required for re-homing Shim6
communications (e.g. [16]). communications (e.g. [12]).
4.2. Ingress Filtering 4.2. Ingress Filtering
Ingress filtering mechanisms [17][18] may drop the outgoing packets Ingress filtering mechanisms [13][14] may drop the outgoing packets
when multiple bi-directional tunnels end up at different HAs. This when multiple bi-directional tunnels end up at different HAs. This
could particularly occur if different MNPs are handled by different could particularly occur if different MNPs are handled by different
HAs. If a packet with a source address configured from a specific HAs. 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 is tunneled to a home agent that does not handle that specific
MNP the packet may be discarded either by the home agent or by a MNP the packet may be discarded either by the home agent or by a
border gateway in the home network. border router in the home network.
The ingress filtering compatibility issue is heavily dependent on the The ingress filtering compatibility issue is heavily dependent on the
particular NEMO multihoming configuration: particular NEMO multihoming configuration:
o For the (*,*,1) cases, there is not such an issue, since there is o For the (*,*,1) cases, there is not such an issue, since there is
a single MNP. a single MNP.
o For the (1,1,*) and (n,1,1) cases, there is not such a problem, o For the (1,1,*) and (n,1,1) cases, there is not such a problem,
since there is a single HA, accepting all the MNPs. since there is a single HA, accepting all the MNPs.
o For the (n,1,n) case, though ingress filtering would not occur at o For the (n,1,n) case, though ingress filtering would not occur at
the HA, it may occur at the MRs, when each MR is handling the HA, it may occur at the MRs, when each MR is handling
different MNPs. different MNPs.
o (*,n,n) are the cases where the ingress filtering presents some o (*,n,n) are the cases where the ingress filtering presents some
difficulties. In the (1,n,n) case, the problem is simplified difficulties. In the (1,n,n) case, the problem is simplified
because all the traffic from and to the NEMO is routed through a because all the traffic from and to the NEMO is routed through a
single MR. Such configuration allows the MR to properly route single MR. Such configuration allows the MR to properly route
packets respecting the constraints imposed by ingress filtering. packets respecting the constraints imposed by ingress filtering.
In this case, the single MR may face ingress filtering problems
that a multihomed mobile node may face, as documented in [7].
The more complex case is the (n,n,n) case. A simplified case In this case, the single MR may face ingress filtering problems
occurs when all the prefixes are accepted by all the HAs, so that that a multihomed mobile node may face, as documented in [7]. The
no problems occur with the ingress filtering. However, this more complex case is the (n,n,n) case. A simplified case occurs
cannot be always assumed, resulting in the problem described when all the prefixes are accepted by all the HAs, so that no
below. 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: the mobile network has two mobile scenario illustrated in Figure 9: the mobile network has two mobile
routers MR1 and MR2, with home agents HA1 and HA2 respectively. Two routers MR1 and MR2, with home agents HA1 and HA2 respectively. Two
bi-directional tunnels are established between the two pairs. Each bi-directional tunnels are established between the two pairs. Each
mobile router advertises a different MNP (P1 and P2 respectively). mobile router advertises a different MNP (P1 and P2 respectively).
MNP P1 is registered to HA1, and MNP P2 is registered to HA2. Thus, MNP P1 is registered to HA1, and MNP P2 is registered to HA2. Thus,
MNNs should be free to auto-configure their addresses on any of P1 or MNNs should be free to auto-configure their addresses on any of P1 or
P2. Ingress filtering could thus happen in two cases: P2. Ingress filtering could thus 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 [15] practice that an IPv6 node is free normal Neighbor Discovery [11] 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. prefix it chooses to use.
o If the tunnel to HA1 is broken, packets that would normally be o If the tunnel to HA1 is broken, packets that would normally be
sent through the tunnel to HA1 should be diverted through the sent through the tunnel to HA1 should be diverted through the
tunnel to HA2. If HA2 (or some border gateway in the domain of tunnel to HA2. If HA2 (or some border router in HA2's domain)
HA2) performs ingress filtering, packets with source address performs ingress filtering, packets with source address configured
configured from MNP P1 may be discarded. from MNP P1 may be discarded.
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
Possible solutions to the ingress filtering incompatibility problem Possible solutions to the ingress filtering incompatibility problem
may be based on the following approaches: may be based on the following approaches:
o Some form of source address dependent routing, whether host-based o Some form of source address dependent routing, whether host-based
and/or router-based where the prefix contained in the source and/or router-based where the prefix contained in the source
address of the packet is considered when deciding which exit address of the packet is considered when deciding which exit
router to use when forwarding the packet. router to use when forwarding the packet.
o The usage of nested tunnels for (*,n,n) cases. Appendix B o The usage of nested tunnels for (*,n,n) cases. Appendix B
describes one such approach. describes one such approach.
o Deprecating those prefixes associated to non-available exit o Deprecating those prefixes associated to non-available exit
routers routers.
The ingress filtering incompatibilities problems that appear in some The ingress filtering incompatibilities problems that appear in some
NEMO multihoming configurations are similar to those considered in NEMO multihoming configurations are similar to those considered in
Shim6 (eg. see [19]). Shim6 (e.g. see [15]).
4.3. HA Synchronization 4.3. HA Synchronization
In the (*,n,*) configuration, a single MNP would be registered at In the (*,n,*) configuration, a single MNP would be registered at
different HAs. This gives rise to the following cases: 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 if This may pose a problem in the routing infrastructure as a whole if
the HAs are located in different administrative domains. The the HAs are located in different administrative domains. The
implications of this aspect needs further exploration. Certain level implications of this aspect needs further exploration. Certain level
of HA co-ordination may be required. A possible approach is to adopt of HA co-ordination may be required. A possible approach is to adopt
a HA synchronization mechanism such as that described in [20] and a HA synchronization mechanism such as that described in [16] and
[21]. Such synchronization might also be necessary in a (*,n,*) [17]. Such synchronization might also be necessary in a (*,n,*)
configuration, when a MR sends binding update messages to only one HA configuration, when a MR sends binding update messages to only one HA
(instead of all HAs). In such cases, the binding update information (instead of all HAs). In such cases, the binding update information
might have to be synchronized between HAs. The mode of might have to be synchronized between HAs. The mode of
synchronization may be either primary-secondary or peer-to-peer. In synchronization may be either primary-secondary or peer-to-peer. In
addition, when a MNP is delegated to the MR (see Section 4.5), some addition, when a MNP is delegated to the MR (see Section 4.5), some
level of co-ordination between the HAs may also be necessary. level of co-ordination between the HAs may also be necessary.
This issue is a general mobility issue that will also have to be This issue is a general mobility issue that will also have to be
dealt with by Mobile IPv6 as well as NEMO Basic Support. dealt with by Mobile IPv6 as well as NEMO Basic Support.
4.4. MR Synchronization 4.4. MR Synchronization
In the (n,*,*) configurations, there are common decisions which may In the (n,*,*) configurations, there are common decisions which may
require synchronization among different MRs [22], such as: require synchronization among different MRs [18], such as:
o advertising the same MNP in the (n,*,1) configurations (see also o advertising the same MNP in the (n,*,1) configurations (see also
"prefix delegation" in Section 4.5); "prefix delegation" in Section 4.5);
o one MR relaying the advertisement of the MNP from another failed o one MR relaying the advertisement of the MNP from another failed
MR in the (n,*,n) configuration; and MR in the (n,*,n) configuration; and
o relaying between MRs everything that needs to be relayed, such as o relaying between MRs everything that needs to be relayed, such as
data packets, creating a tunnel from the ingress interface, etc, data packets, creating a tunnel from the ingress interface, etc,
in the (n,*,*) configuration. in the (n,*,*) configuration.
skipping to change at page 25, line 10 skipping to change at page 25, line 47
o for the (*,n,1) cases, how can multiple HAs delegate the same MNP o for the (*,n,1) cases, how can multiple HAs delegate the same MNP
to the mobile network? For doing so, the HAs may be somehow to the mobile network? For doing so, the HAs may be somehow
configured to advertise the same MNP (see also "HA configured to advertise the same MNP (see also "HA
Synchronization" in Section 4.3). Synchronization" in Section 4.3).
o for the (n,*,1) cases, how can multiple MRs be synchronized to o for the (n,*,1) cases, how can multiple MRs be synchronized to
advertise the same MNP down the NEMO-link? For doing so, the MRs advertise the same MNP down the NEMO-link? For doing so, the MRs
may be somehow configured to advertise the same MNP (see also "MR may be somehow configured to advertise the same MNP (see also "MR
Synchronization" in Section 4.4). Synchronization" in Section 4.4).
Prefix delegation mechanisms [23][24][25] could be used to ensure all Prefix delegation mechanisms [19][20][21] could be used to ensure all
routers advertise the same MNP. Their application to a multihomed routers advertise the same MNP. Their applicability to a multihomed
mobile network should be considered. mobile network should be considered.
4.6. Multiple Bindings/Registrations 4.6. 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 mobility issue, since Mobile IPv6 nodes face a This is a generic mobility issue, since Mobile IPv6 nodes face a
similar problem. This issue is discussed in [7]. It is sufficient similar problem. This issue is discussed in [7]. It is sufficient
to note that solutions like [26] can solve this for both Mobile IPv6 to note that solutions like [22] can solve this for both Mobile IPv6
and NEMO Basic Support. This issue is being dealt with in the and NEMO Basic Support. This issue is being dealt with in the
Monami6 WG. Monami6 WG.
4.7. Source Address Selection 4.7. Source Address Selection
In the (*,*,n) configurations, MNNs would be configured with multiple In the (*,*,n) configurations, MNNs would be configured with multiple
addresses. Source address selection mechanisms are needed to decide addresses. Source address selection mechanisms are needed to decide
which address to choose from. which address to choose from.
However, currently available source address selection mechanisms do However, currently available source address selection mechanisms do
not allow MNNs to acquire sufficient information to select their not allow MNNs to acquire sufficient information to select their
source addresses intelligently (such as based on the traffic source addresses intelligently (such as based on the traffic
condition associated with the home network of each MNP). It may be condition associated with the home network of each MNP). It may be
desirable for MNNs to be able to acquire "preference" information on desirable for MNNs to be able to acquire "preference" information on
each MNP from the MRs. This would allow default address selection each MNP from the MRs. This would allow default address selection
mechanisms such as those specified in [27] to be used. Further mechanisms such as those specified in [23] to be used. Further
exploration on setting such "preference" information in Router exploration on setting such "preference" information in Router
Advertisement based on performance of the bi-directional tunnel might Advertisement based on performance of the bi-directional tunnel might
prove to be useful. Note that source address selection may be prove to be useful. Note that source address selection may be
closely related to path selection procedures (see Section 4.1.3) and closely related to path selection procedures (see Section 4.1.3) and
re-homing techniques (see Section 4.1.4). re-homing techniques (see Section 4.1.4).
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. prefixes.
4.8. Loop Prevention in Nested Mobile Networks 4.8. Loop Prevention in 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 to two different root-MRs, thus nested mobile network may be attached to two different root-MRs, thus
the aggregated network no longer forms a simple tree structure. In the aggregated network no longer forms a simple tree structure. In
such a situation, infinite loop within the mobile network may occur. such a situation, infinite loop within the mobile network may occur.
This problem is specific to NEMO Basic Support. However, at the time This problem is specific to NEMO Basic Support. However, at the time
of writing, more research is recommended to assess the probability of of writing, more research is recommended to assess the probability of
loops occurring in a multihomed mobile network. For related work, loops occurring in a multihomed mobile network. For related work,
see [28] for a mechanism to avoid loops in nested NEMO. see [24] for a mechanism to avoid loops in nested NEMO.
4.9. Prefix Ownership 4.9. 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), MRs on distinct links may try to register the only available up), MRs on distinct links may try to register the only available
MNP. This cannot be allowed, as the HA has no way to know which node MNP. This cannot be allowed, as the HA has no way to know which node
with an address configured from that MNP is attached to which MR. with an address configured from that MNP is attached to which MR.
Some mechanism must be present for the MNP to either be forcibly Some mechanism must be present for the MNP to either be forcibly
removed from one (or all) MRs, or the implementors must not allow a removed from one (or all) MRs, or the implementors must not allow a
(n,*,1) network to split. (n,*,1) network to split.
A possible approach to solving this problem is described in [29]. A possible approach to solving this problem is described in [25].
This problem is specific to NEMO Basic Support. However, it is This problem is specific to NEMO Basic Support. However, it is
unclear whether there is sufficient deployment scenario for this unclear whether there is sufficient deployment scenario for this
problem to occur. problem to occur.
It is recommended that the NEMO WG standardizes a solution to solve It is recommended that the NEMO WG standardizes a solution to solve
this problem if there is sufficient vendor/operator interest, or this problem if there is sufficient vendor/operator interest, or
specifies that the split of a (n,*,1) network cannot be allowed specifies that the split of a (n,*,1) network cannot be allowed
without a router renumbering. without a router renumbering.
skipping to change at page 28, line 24 skipping to change at page 29, line 24
| # of MRs: | 1 | 1 | 1 | 1 | n | n | n | n | | # of MRs: | 1 | 1 | 1 | 1 | n | n | n | n |
| # of HAs: | 1 | 1 | n | n | 1 | 1 | n | n | | # of HAs: | 1 | 1 | n | n | 1 | 1 | n | n |
| # of Prefixes: | 1 | n | 1 | n | 1 | n | 1 | n | | # of Prefixes: | 1 | n | 1 | n | 1 | n | 1 | n |
+=================================================================+ +=================================================================+
| Fault Tolerance | * | * | * | * | * | * | * | * | | Fault Tolerance | * | * | * | * | * | * | * | * |
+---------------------------------+---+---+---+---+---+---+---+---+ +---------------------------------+---+---+---+---+---+---+---+---+
| Failure Detection |N/M|N/M|N/M|N/M|N/M|N/M| N | S | | 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 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| | Path Selection | N |S/M| M |S/M| N |S/N| N |S/N|
+---------------------------------+---+---+---+---+---+---+---+---+ +---------------------------------+---+---+---+---+---+---+---+---+
| Re-Homing |N/M| S |N/M| S |N/M| S |N/M| S | | Re-Homing |N/M| S |N/M| S |N/M| S |N/M| S |
+---------------------------------+---+---+---+---+---+---+---+---+ +---------------------------------+---+---+---+---+---+---+---+---+
| Ingress Filtering | . | . | . | t | . | . | . | N | | Ingress Filtering | . | . | . | t | . | . | . | N |
+---------------------------------+---+---+---+---+---+---+---+---+ +---------------------------------+---+---+---+---+---+---+---+---+
| HA Synchronization | . | . |N/M|N/M| . | . |N/M|N/M| | HA Synchronization | . | . |N/M|N/M| . | . |N/M|N/M|
+---------------------------------+---+---+---+---+---+---+---+---+ +---------------------------------+---+---+---+---+---+---+---+---+
| MR Synchronization | . | . | . | . | G | G | G | G | | MR Synchronization | . | . | . | . | G | G | G | G |
+---------------------------------+---+---+---+---+---+---+---+---+ +---------------------------------+---+---+---+---+---+---+---+---+
| Prefix Delegation | . | . | N | N | N | N | N | N | | Prefix Delegation | . | . | N | N | N | N | N | N |
skipping to change at page 28, line 52 skipping to change at page 29, line 52
| Prefix Ownership | . | . | . | . | N | . | N | . | | Prefix Ownership | . | . | . | . | N | . | N | . |
+---------------------------------+---+---+---+---+---+---+---+---+ +---------------------------------+---+---+---+---+---+---+---+---+
| Preference Settings | G | G | G | G | G | G | G | G | | Preference Settings | G | G | G | G | G | G | G | G |
+=================================================================+ +=================================================================+
N - NEMO Specific M - MIPv6 Specific G - Generic IPv6 N - NEMO Specific M - MIPv6 Specific G - Generic IPv6
S - SHIM6 WG D - DNA WG S - SHIM6 WG D - DNA WG
. - Not an Issue t - trivial . - Not an Issue t - trivial
* - Fault Tolerance is a combination of Failure Detection, Path * - Fault Tolerance is a combination of Failure Detection, Path
Exploration, Path Selection, and Re-Homing Exploration, Path Selection, and Re-Homing
Figure 10: Matrix of NEMO Multihoming Issues Figure 10: Matrix of NEMO Multihoming Issues
The above matrix serves to identify which issues are NEMO-specific, The above matrix serves to identify which issues are NEMO-specific,
and which are not. The readers are reminded that this matrix is a and which are not. The readers are reminded that this matrix is a
simplification of Section 4 as subtle details are not represented in simplification of Section 4 as subtle details are not represented in
Figure 10. Figure 10.
As can be seen from Figure 10, the following have some concerns which As can be seen from Figure 10, the following have some concerns which
are specific to NEMO: Failure Detection, Path Exploration, Path are specific to NEMO: Failure Detection, Path Exploration, Path
Selection, Re-Homing, Ingress Filtering, HA Synchronization, Prefix Selection, Re-Homing, Ingress Filtering, HA Synchronization, Prefix
Delegation, Loop Prevention in Nested NEMO, and Prefix Ownership. Delegation, Loop Prevention in Nested NEMO, and Prefix Ownership.
Based on the authors' best knowledge of the possible deployments of Based on the authors' best knowledge of the possible deployments of
NEMO, it is recommended that: NEMO, it is recommended that:
o A solution for Failure Detection, Path Exploration, Path o A solution for Failure Detection, Path Exploration, Path
Selection, and Re-Homing be solicited from other WGs Selection, and Re-Homing be solicited from other WGs.
Although Path Selection is reflected in Figure 10 as NEMO- Although Path Selection is reflected in Figure 10 as NEMO-
Specific, the technical consideration of the problem is believed Specific, the technical consideration of the problem is believed
to be quite similar to the selection of multiple paths in mobile to be quite similar to the selection of multiple paths in mobile
nodes. As such, we would recommend vendors to solicit a solution nodes. As such, we would recommend vendors to solicit a solution
for these issues from other WGs in the IETF, for instance the for these issues from other WGs in the IETF, for instance the
Monami6 or Shim6 WG. Monami6 or Shim6 WG.
o Ingress Filtering on the (n,n,n) configuration be solved by the o Ingress Filtering on the (n,n,n) configuration be solved by the
NEMO WG NEMO WG.
This problem is clearly defined, and can be solved by the WG. This problem is clearly defined, and can be solved by the WG.
Deployment of the (n,n,n) configuration can be envisioned on Deployment of the (n,n,n) configuration can be envisioned on
vehicles for mass transportation (such as buses, trains) where vehicles for mass transportation (such as buses, trains) where
different service providers may install their own mobile routers different service providers may install their own mobile routers
on the vehicle/vessel. on the vehicle/vessel.
It should be noted that the Shim6 WG may be developing a mechanism It should be noted that the Shim6 WG may be developing a mechanism
for overcoming ingress filtering in a more general sense. We thus for overcoming ingress filtering in a more general sense. We thus
recommend the NEMO WG to concentrate only on the (n,n,n) recommend the NEMO WG to concentrate only on the (n,n,n)
configuration should the WG decide to work on this issue. configuration should the WG decide to work on this issue.
o A solution for Home Agent Synchronization be looked at in a o A solution for Home Agent Synchronization be looked at in a
mobility specific WG and taking into consideration both mobile mobility specific WG and taking into consideration both mobile
hosts operating Mobile IPv6 and mobile routers operating NEMO hosts operating Mobile IPv6 and mobile routers operating NEMO
Basic Support. Basic Support.
o A solution for Multiple Bindings/Registrations be presently looked o A solution for Multiple Bindings/Registrations be presently looked
at by the Monami6 WG. at by the Monami6 WG.
o Prefix Delegation be reviewed and checked by the NEMO WG o Prefix Delegation be reviewed and checked by the NEMO WG.
There are already WG drafts and [30] providing prefix delegation The proposed solutions [21] and [20] providing prefix delegation
functionality to NEMO Basic Support. The WG should review these functionality to NEMO Basic Support should be reviewed in order to
drafts and verified that they address any concern a multihomed make sure concerns as discussed in Section 4.5 are properly
NEMO might have, as discussed in Section 4.5. handled.
o Loop Prevention in Nested NEMO be investigated o Loop Prevention in Nested NEMO be investigated.
Further research is recommended to assess the risk of having a Further research is recommended to assess the risk of having a
loop in the nesting of multihomed mobile networks. loop in the nesting of multihomed mobile networks.
o Prefix Ownership should be considered by the vendors and operators o Prefix Ownership should be considered by the vendors and
operators.
The problem of Prefix Ownership only occurs when a mobile network The problem of Prefix Ownership only occurs when a mobile network
with multiple MRs and a single MNP can arbitrarily join and split. with multiple MRs and a single MNP can arbitrarily join and split.
Vendors and operators of mobile networks are encouraged to input Vendors and operators of mobile networks are encouraged to input
their views on the applicability of deploying such kind of mobile their views on the applicability of deploying such kind of mobile
networks. networks.
6. Conclusion 6. Conclusion
This memo is an analysis of multihoming in the context of network This memo presented an analysis of multihoming in the context of
mobility under the operation of NEMO Basic Support. The purpose of network mobility under the operation of NEMO Basic Support (RFC
this memo is to investigate issues related to such a bi-directional 3963). The purpose was to investigate issues related to such a bi-
tunneling mechanism when mobile networks are multihomed. For doing directional tunneling mechanism where mobile networks are multihomed
so, a taxonomy was proposed to classify the mobile networks in eight and multiple bi-directional tunnels established between home agent
possible multihomed configurations. The issue were explained and and mobile router pairs. For doing so, mobile networks were
were then summarized in a table showing under which multihoming classified into a taxonomy comprising eight possible multihomed
configuration it applies, and which IETF working group is the best configurations. Issues were explained one by one and then summarized
chartered to solve it. This analysis will be helpful to extend the into a table showing the multihomed configurations where they apply
existing standards to support multihoming and to implementors of NEMO and suggesting the most relevant IETF working group where they could
Basic Support and multihoming-related mechanisms. be solved. This analysis will be helpful to extend the existing
standards to support multihoming and to implementors of NEMO Basic
Support and multihoming-related mechanisms.
7. IANA Considerations 7. IANA Considerations
This is an informational document and does not require any IANA This is an informational document and as such does not require any
action. IANA action.
8. Security Considerations 8. Security Considerations
This is an informational document where the multihoming This is an informational document where the multihoming
configurations under the operation of NEMO Basic Support are configurations under the operation of NEMO Basic Support are
analyzed. Security considerations of these multihoming analyzed. Security considerations of these multihoming
configurations, should they be different from those that concern NEMO configurations, should they be different from those that concern NEMO
Basic Support, must be considered by forthcoming solutions. Basic Support, must be considered by forthcoming solutions.
9. Acknowledgments 9. Acknowledgments
skipping to change at page 32, line 9 skipping to change at page 33, line 9
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.
The initial evaluation of NEMO Basic Support on multihoming The initial evaluation of NEMO Basic Support on multihoming
configurations is a contribution from Julien Charbon. configurations is a contribution from Julien Charbon.
10. References 10. References
10.1. Normative References 10.1. Normative References
[1] Ernst, T., "Network Mobility Support Goals and Requirements", [1] Ernst, T., "Network Mobility Support Goals and Requirements",
draft-ietf-nemo-requirements-05 (work in progress), draft-ietf-nemo-requirements-06 (work in progress),
October 2005. November 2006.
[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",
draft-ietf-nemo-terminology-05 (work in progress), draft-ietf-nemo-terminology-06 (work in progress),
February 2006. November 2006.
[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.
10.2. Informative References 10.2. Informative References
[6] Ernst, T., "Motivations and Scenarios for Using Multiple [6] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K.
Kuladinithi, "Motivations and Scenarios for Using Multiple
Interfaces and Global Addresses", Interfaces and Global Addresses",
draft-ietf-monami6-multihoming-motivation-scenario-00 (work in draft-ietf-monami6-multihoming-motivation-scenario-01 (work in
progress), February 2006. progress), October 2006.
[7] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. [7] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K.
Kuladinithi, "Analysis of Multihoming in Mobile IPv6", Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
draft-ietf-monami6-mipv6-analysis-00 (work in progress), draft-ietf-monami6-mipv6-analysis-00 (work in progress),
February 2006. February 2006.
[8] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair [8] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair
Exploration Protocol for IPv6 Multihoming", Exploration Protocol for IPv6 Multihoming",
draft-ietf-shim6-failure-detection-03 (work in progress), draft-ietf-shim6-failure-detection-07 (work in progress),
December 2005. December 2006.
[9] Beijnum, I., "Shim6 Reachability Detection",
draft-ietf-shim6-reach-detect-01 (work in progress),
October 2005.
[10] Yegin, A., "Link-layer Event Notifications for Detecting
Network Attachments", draft-ietf-dna-link-information-03 (work
in progress), October 2005.
[11] Narayanan, S., "Detecting Network Attachment in IPv6 - Best
Current Practices for hosts.", draft-ietf-dna-hosts-02 (work in
progress), October 2005.
[12] Yegin, A., "Link-layer Hints for Detecting Network
Attachments", draft-yegin-dna-l2-hints-01 (work in progress),
February 2004.
[13] Yegin, A., "Supporting Optimized Handover for IP Mobility [9] Krishnan, S., Montavont, N., Yegin, A., Veerepalli, S., and A.
-Requirements for Underlying Systems", Yegin, "Link-layer Event Notifications for Detecting Network
draft-manyfolks-l2-mobilereq-02 (work in progress), July 2002. Attachments", draft-ietf-dna-link-information-05 (work in
progress), November 2006.
[14] Narayanan, S., "Detecting Network Attachment in IPv6 - Best [10] Narayanan, S., "Detecting Network Attachment in IPv6 Networks
Current Practices for Routers", draft-ietf-dna-routers-01 (work (DNAv6)", draft-ietf-dna-protocol-03.txt (work in progress),
in progress), October 2005. October 2006.
[15] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [11] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[16] Bagnulo, M. and J. Arkko, "Functional decomposition of the [12] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim
multihoming protocol", draft-ietf-shim6-functional-dec-00 (work protocol", draft-ietf-shim6-proto-07 (work in progress),
in progress), July 2005. November 2006.
[17] Ferguson, P. and D. Senie, "Network Ingress Filtering: [13] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[18] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [14] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[19] Huitema, C., "Ingress filtering compatibility for IPv6 [15] Huitema, C. and M. Marcelo, "Ingress filtering compatibility
multihomed sites", draft-huitema-shim6-ingress-filtering-00 for IPv6 multihomed sites",
(work in progress), September 2005. draft-huitema-shim6-ingress-filtering-00 (work in progress),
October 2006.
[20] Wakikawa, R., Devarapalli, V., and P. Thubert, "Inter Home [16] Wakikawa, R., Devarapalli, V., and P. Thubert, "Inter Home
Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work
in progress), February 2004. in progress), February 2004.
[21] Koh, B., Ng, C., and J. Hirano, "Dynamic Inter Home Agent [17] Koh, B., Ng, C., and J. Hirano, "Dynamic Inter Home Agent
Protocol", draft-koh-mip6-nemo-dhap-00 (work in progress), Protocol", draft-koh-mip6-nemo-dhap-00 (work in progress),
July 2004. July 2004.
[22] Tsukada, M., "Analysis of Multiple Mobile Routers Cooperation", [18] Tsukada, M., "Analysis of Multiple Mobile Routers Cooperation",
draft-tsukada-nemo-mr-cooperation-analysis-00 (work in draft-tsukada-nemo-mr-cooperation-analysis-00 (work in
progress), October 2005. progress), October 2005.
[23] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix [19] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
Delegation", RFC 3769, June 2004. Delegation", RFC 3769, June 2004.
[24] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", [20] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO",
draft-droms-nemo-dhcpv6-pd-02 (work in progress), April 2005. draft-ietf-nemo-dhcpv6-pd-02 (work in progress),
September 2006.
[25] Kniveton, T. and P. Thubert, "Mobile Network Prefix [21] Thubert, P. and TJ. Kniveton, "Mobile Network Prefix
Delegation", draft-ietf-nemo-prefix-delegation-00 (work in Delegation", draft-ietf-nemo-prefix-delegation-01 (work in
progress), August 2005. progress), November 2006.
[26] Wakikawa, R., "Multiple Care-of Addresses Registration", [22] Wakikawa, R., "Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-00 (work in progress), draft-ietf-monami6-multiplecoa-00 (work in progress),
June 2006. June 2006.
[27] Draves, R., "Default Address Selection for Internet Protocol [23] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003. version 6 (IPv6)", RFC 3484, February 2003.
[28] Thubert, P., "Nested Nemo Tree Discovery", [24] Thubert, P., Bontous, C., and N. Nicolas, "Nested Nemo Tree
draft-thubert-tree-discovery-02 (work in progress), July 2005. Discovery", draft-thubert-tree-discovery-04 (work in progress),
November 2006.
[29] Kumazawa, M., "Token based Duplicate Network Detection for [25] Kumazawa, M., "Token based Duplicate Network Detection for
split mobile network (Token based DND)", split mobile network (Token based DND)",
draft-kumazawa-nemo-tbdnd-02 (work in progress), July 2005. draft-kumazawa-nemo-tbdnd-02 (work in progress), July 2005.
[30] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO",
draft-ietf-nemo-dhcpv6-pd-00 (work in progress), August 2005.
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 39, line 28 skipping to change at page 40, line 28
In the remaining part of this Appendix, we will attempt to In the remaining part of this Appendix, we will attempt to
investigate methods of performing such re-establishment of bi- investigate methods of performing such re-establishment of bi-
directional tunnels. This method of tunnel re-establishment is directional tunnels. This method of tunnel re-establishment is
particularly useful for the (*,n,n) NEMO configuration. The method particularly useful for the (*,n,n) NEMO configuration. The method
described is by no means complete and merely serves as a suggestion described is by no means complete and merely serves as a suggestion
on how to approach the problem. It is also not the objective to on how to approach the problem. It is also not the objective to
specify a new protocol specifically tailored to provide this form of specify a new protocol specifically tailored to provide this form of
re- establishments. Instead, we will limit ourselves to currently re- establishments. Instead, we will limit ourselves to currently
available mechanisms specified in Mobile IPv6 [5] and Neighbor available mechanisms specified in Mobile IPv6 [5] and Neighbor
Discovery in IPv6 [15]. Discovery in IPv6 [11].
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 42, line 7 skipping to change at page 43, line 7
other MRs identify which prefix they have to use to configure the new other MRs identify which prefix they have to use to configure the new
CoA? In this case, there are three prefixes being announced and a MR CoA? In this case, there are three prefixes being announced and a MR
whose link has failed, knows that his prefix is not to be used, but whose link has failed, knows that his prefix is not to be used, but
it has not enough information to decide which one of the other two it has not enough information to decide which one of the other two
prefixes to use to configure the new CoA. In such cases, a mechanism prefixes to use to configure the new CoA. In such cases, a mechanism
is needed to allow a MR to withdraw its own prefix when it discovers is needed to allow a MR to withdraw its own prefix when it discovers
that its link is no longer working. that its link is no longer working.
Appendix C. Change Log Appendix C. Change Log
o This draft is an update of draft-ng-nemo-multihoming-issues-03.txt o Changes from draft-ietf-nemo-multihoming-issues-06 to -07:
which is itself a merge of 3 previous drafts
draft-ng-nemo-multihoming-issues-02.txt, * Removed in 2.1 the bullet "Multiple global prefixes are
draft-eun-nemo-multihoming-problem-statement-00.txt, and available on the home link, and thus the MR has more than one
draft-charbon-nemo-multihoming-evaluation-00.txt path to reach the home agent."
* In all 2.x sub-sections in the sentence similar to "A bi-
directional tunnel would then be established between each HoA-
CoA pair", replaced the part "HoA-CoA" pair with "{HA address,
CoA} pair."
* Removed in 2.3 ", possibly one HA per HoA, or one HA per egress
interface." and in 2.4 ", possibly one per Home Address (or one
HA per egress interface),"
* In 2.4 and 2.6 and 2.8, replaced "Regarding MNNs, they are
generally multihomed since they would configure a global
address from each MNP available on the link they are attached
to." with the better text in 2.2, i.e. "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."
* In 4.1.1 and 4.1.2 3rd bullet, rephrased the complex sentence
"The (n,n,n) case is hybrid, since for those cases when[4.1.1]/
that[4.1.2] selecting a different prefix result in a change of
path, the Shim6 protocols (such as [9]) may be useful." into
"The (n,n,n) case is hybrid, since selecting a different prefix
results in a change of path. For this case the Shim6 protocols
(such as those discussed in [8]) may be useful."
* Probably due to a typo in the table in section 5 line "Path
Selection", changed "N |S/N| N |S/N| N |S/N| N |S/N|" to "M
|S/M| M |S/M| N |S/N| N |S/N|"
* Removed references to draft-yegin-dna-l2-hints-01 and
draft-manyfolks-l2-mobilereq-02. Should now be covered in
draft-ietf-dna-link-information-05.txt.
* Both draft-droms-nemo-dhcpv6-pd-02 and
draft-ietf-nemo-dhcpv6-pd-00 were cited. Removed the former.
* Replaced references to draft-ietf-dna-hosts-02 and
draft-ietf-dna-routers-01 with draft-ietf-dna-protocol-03.txt
where everything was merged.
* Replaced draft-ietf-shim6-reach-detect-01 with
draft-ietf-shim6-failure-detection
* Replaced draft-ietf-shim6-functional-dec with
draft-ietf-shim6-proto
* Rephrased paragraph about "Prefix Delegation" in section 5.
* Rephrased the conclusion.
* Replaced "visited link" with "foreign link" and "border
gateway" with "border router" in several places.
* Reordered author list.
* And, minor editorial corrections and reference update.
o Changes from draft-ietf-nemo-multihoming-issues-05 to -06: o Changes from draft-ietf-nemo-multihoming-issues-05 to -06:
* Minor editorial corrections and reference update * Minor editorial corrections and reference update
o Changes from draft-ietf-nemo-multihoming-issues-04 to -05: o Changes from draft-ietf-nemo-multihoming-issues-04 to -05:
* Addressed Issue #23: modified text in Sect 4.2: "Ingress * Addressed Issue #23: modified text in Sect 4.2: "Ingress
Filtering" Filtering"
skipping to change at page 45, line 17 skipping to change at page 47, line 17
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: chanwah.ng@sg.panasonic.com Email: chanwah.ng@sg.panasonic.com
Eun Kyoung Paik
KT
Portable Internet Team, Convergence Lab., KT
17 Woomyeon-dong, Seocho-gu
Seoul 137-792
Korea
Phone: +82-2-526-5233
Fax: +82-2-526-5200
Email: euna@kt.co.kr
URI: http://mmlab.snu.ac.kr/~eun/
Thierry Ernst Thierry Ernst
INRIA INRIA
INRIA Rocquencourt INRIA Rocquencourt
Domaine de Voluceau B.P. 105 Domaine de Voluceau B.P. 105
Le Chesnay, 78153 Le Chesnay, 78153
France France
Phone: +33-1-39-63-59-30 Phone: +33-1-39-63-59-30
Fax: +33-1-39-63-54-91 Fax: +33-1-39-63-54-91
Email: thierry.ernst@inria.fr Email: thierry.ernst@inria.fr
URI: http://www.nautilus6.org/~thierry URI: http://www.nautilus6.org/~thierry
Eun Kyoung Paik
KT
Portable Internet Team, Convergence Lab., KT
17 Woomyeon-dong, Seocho-gu
Seoul 137-792
Korea
Phone: +82-2-526-5233
Fax: +82-2-526-5200
Email: euna@kt.co.kr
URI: http://mmlab.snu.ac.kr/~eun/
Marcelo Bagnulo Marcelo Bagnulo
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
Av. Universidad, 30 Av. Universidad, 30
Leganes, Madrid 28911 Leganes, Madrid 28911
Spain Spain
Phone: +34 91624 8837 Phone: +34 91624 8837
Email: marcelo@it.uc3m.es Email: marcelo@it.uc3m.es
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 46, line 29 skipping to change at page 48, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 161 change blocks. 
356 lines changed or deleted 415 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/