draft-ietf-nemo-multihoming-issues-05.txt   draft-ietf-nemo-multihoming-issues-06.txt 
NEMO Working Group C. Ng NEMO Working Group C. Ng
Internet-Draft Panasonic Singapore Labs Internet-Draft Panasonic Singapore Labs
Expires: August 27, 2006 E. Paik Expires: December 24, 2006 E. Paik
KT KT
T. Ernst T. Ernst
Keio University / WIDE INRIA
M. Bagnulo M. Bagnulo
UC3M UC3M
February 23, 2006 June 22, 2006
Analysis of Multihoming in Network Mobility Support Analysis of Multihoming in Network Mobility Support
draft-ietf-nemo-multihoming-issues-05 draft-ietf-nemo-multihoming-issues-06
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 August 27, 2006. This Internet-Draft will expire on December 24, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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 then made as to whether the NEMO Support). Recommendations are offered on how to address these
Working Group should solve these issues, or a solution should be issues.
sought elsewhere.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Classification . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Classification . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. (1,1,1): Single MR, Single HA, Single MNP . . . . . . . . 7 2.1. (1,1,1): Single MR, Single HA, Single MNP . . . . . . . . 7
2.2. (1,1,n): Single MR, Single HA, Multiple MNPs . . . . . . . 8 2.2. (1,1,n): Single MR, Single HA, Multiple MNPs . . . . . . . 8
2.3. (1,n,1): Single MR, Multiple HAs, Single MNP . . . . . . . 8 2.3. (1,n,1): Single MR, Multiple HAs, Single MNP . . . . . . . 8
2.4. (1,n,n): Single MR, Multiple HAs, Multiple MNPs . . . . . 9 2.4. (1,n,n): Single MR, Multiple HAs, Multiple MNPs . . . . . 9
skipping to change at page 3, line 4 skipping to change at page 2, line 49
4.7. Source Address Selection . . . . . . . . . . . . . . . . . 25 4.7. Source Address Selection . . . . . . . . . . . . . . . . . 25
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 . . . . . . . . . . . . . . . . . . . . . 26
4.10. Preference Settings . . . . . . . . . . . . . . . . . . . 26 4.10. Preference Settings . . . . . . . . . . . . . . . . . . . 26
5. Recommendations to the Working Group . . . . . . . . . . . . . 28 5. Recommendations to the Working Group . . . . . . . . . . . . . 28
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Normative References . . . . . . . . . . . . . . . . . . . 32 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
10.2. Informative References . . . . . . . . . . . . . . . . . . 32 10.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Alternative Classifications Approach . . . . . . . . 35 Appendix A. Alternative Classifications Approach . . . . . . . . 35
A.1. Ownership-Oriented Approach . . . . . . . . . . . . . . . 35 A.1. Ownership-Oriented Approach . . . . . . . . . . . . . . . 35
A.1.1. ISP Model . . . . . . . . . . . . . . . . . . . . . . 35 A.1.1. ISP Model . . . . . . . . . . . . . . . . . . . . . . 35
A.1.2. Subscriber/Provider Model . . . . . . . . . . . . . . 36 A.1.2. Subscriber/Provider Model . . . . . . . . . . . . . . 36
skipping to change at page 5, line 7 skipping to change at page 5, line 7
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 objective of this memo
is thus multi-folded: is thus multi-folded:
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 those 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 those 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 identify potential solutions to the previously identified
issues. issues; and
o to decide which issues are worth to be solved, and to determine o to decide which issues are worth to be solved, and to determine
which WG should address each of the issues that are worth solving. which WG should address each of the issues that are worth solving.
In order to reach these objectives, a taxonomy to classify the In order to reach these objectives, a taxonomy to classify 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], Goals and Benefits of Multihoming [6], Goals [2] (section 3) and [3], Motivations and and Scenarios for
and Requirements of Network Mobility Support [1], and the NEMO Basic Multihoming [6], Goals and Requirements of Network Mobility Support
Support specification [4]. Goals and benefits of multihoming as [1], and the NEMO Basic Support specification [4]. Goals and
discussed in [6] are applicable to fixed nodes, mobile nodes, fixed benefits of multihoming as discussed in [6] are applicable to fixed
networks and mobile networks. nodes, mobile 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 52 skipping to change at page 6, line 52
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 to 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 visited link), or (ii) the MR is equipped with
multiple interfaces. In such a case, the MR would have multiple Home multiple interfaces. In such a case, the MR would have multiple HoA-
Address / Care-of Address pairs. Issues pertaining to a multihomed CoA pairs. Issues pertaining to a multihomed MR are also addressed
MR are also addressed in [7]. In addition, the readers should also in [7]. In addition, the readers should also keep in mind that when
keep in mind that when "MNP(s) is/are available in the NEMO", the "MNP(s) is/are available in the NEMO", the MNP(s) may either be
MNP(s) may either be explicitly announced by the MR via router explicitly announced by the MR via router advertisement, or made
advertisement, or made available through Dynamic Host Configuration available through Dynamic Host Configuration Protocol (DHCP).
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 its has multiple CoAs;
skipping to change at page 7, line 35 skipping to change at page 7, line 34
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 visited 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 MR is attached,
thus prefixes available on the foreign link are not announced on the thus prefixes available on the foreign link are not announced on the
NEMO link. For the case where multiple prefixes are available on the NEMO link. For the case where multiple prefixes are available on the
home link, these are only announced on the NEMO link if the MR is home link, these are only announced on the NEMO link if the MR is
configured to do so. In this configuration, only one MNP is configured to do so. In this configuration, only one MNP is
announced. announced.
A bi-directional tunnel would then be established between each pair A bi-directional tunnel would then be established between each HoA-
of Home Address / Care-of 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 _ | |
|_|-|<-_ |-|_|-| |-| _ |_|-|<-_ |-|_|-| |-| _
_ |-|_|=| |_____| | _ |-|_| _ |-|_|=| |_____| | _ |-|_|
|_|-| | |-|_|-| |_|-| | |-|_|-|
skipping to change at page 8, line 12 skipping to change at page 8, line 12
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. In such
a case, a bi-directional tunnel would be established between each a case, a bi-directional tunnel would be established between each
pair of Home Address / Care-of Address. HoA-CoA 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 with each MNP available on the link.
_____ _____
_ p1,p2 _ | | _ p1,p2 _ | |
|_|-|<-_ |-|_|-| |-| _ |_|-|<-_ |-|_|-| |-| _
_ |-|_|=| |_____| | _ |-|_| _ |-|_|=| |_____| | _ |-|_|
|_|-| | |-|_|-| |_|-| | |-|_|-|
| |
MNNs MR AR Internet AR HA MNNs MR AR Internet AR HA
Figure 2: (1,1,n): 1 MR, 1 HA, multiple MNPs Figure 2: (1,1,n): 1 MR, 1 HA, multiple MNPs
2.3. (1,n,1): Single MR, Multiple HAs, Single MNP 2.3. (1,n,1): Single MR, Multiple HAs, Single MNP
The (1,n,1) 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 Home Address, or one HA per egress HAs, possibly one HA per HoA, or one HA per egress interface.
interface.
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 pair of directional tunnel would then be established between each HoA-CoA
Home Address / Care-of Address. 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 _ | |-|
skipping to change at page 9, line 28 skipping to change at page 9, line 28
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, possibly one per Home Address (or one
HA per egress interface), and more than one MNP is available in the HA per egress interface), and more than one MNP is available in 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 pair of Home Address / tunnel would then be established between each HoA-CoA pair.
Care-of Address.
Regarding MNNs, they are generally multihomed since they would Regarding MNNs, they are generally multihomed since they would
configure a global address from each MNP available on the link they configure a global address from each MNP available on the link they
are attached to. are attached to.
AR HA2 AR HA2
_ | _ _ | _
_____ |-|_|-|-|_| _____ |-|_|-|-|_|
_ p1,p2 _ | |-| | _ p1,p2 _ | |-| |
|_|-|<-_ |-|_|-| | _ |_|-|<-_ |-|_|-| | _
skipping to change at page 10, line 13 skipping to change at page 10, line 13
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 pair of directional tunnel would then be established between each HoA-CoA
Home Address / Care-of Address. 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<-_ |
_ |-|_|-| _____ _ |-|_|-| _____
|_|-| |-| | |_|-| |-| |
_ | | |-| _ _ | | |-| _
skipping to change at page 10, line 40 skipping to change at page 10, line 40
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 pair of directional tunnel would then be established between each HoA-CoA
Home Address / Care-of Address. pair.
Regarding MNNs, they are generally multihomed since they would Regarding MNNs, they are generally multihomed since they would
configure a global address from each MNP available on the link they configure a global address from each MNP available on the link they
are attached to. are attached to.
MR2 MR2
p2<-_ | p2<-_ |
_ |-|_|-| _____ _ |-|_|-| _____
|_|-| |-| | |_|-| |-| |
_ | | |-| _ _ | | |-| _
skipping to change at page 11, line 26 skipping to change at page 11, line 26
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 then be established between
each pair of Home Address / Care-of Address. each HoA-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 _ |
<-_ | |-|_|-| _ <-_ | |-|_|-| _
_ |-|_|-| _____ | |-|_| _ |-|_|-| _____ | |-|_|
|_|-| |-| |-| |_|-| |-| |-|
skipping to change at page 12, line 14 skipping to change at page 12, line 14
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 then be established between
each pair of Home Address / Care-of Address. each HoA-CoA pair.
Regarding MNNs, they are generally multihomed since they would Regarding MNNs, they are generally multihomed since they would
configure a global address from each MNP available on the link they configure a global address from each MNP available on the link they
are attached to. are attached to.
MR2 AR HA2 MR2 AR HA2
p2 _ | p2 _ |
<-_ | |-|_|-| _ <-_ | |-|_|-| _
_ |-|_|-| _____ | |-|_| _ |-|_|-| _____ | |-|_|
|_|-| |-| |-| |_|-| |-| |-|
skipping to change at page 14, line 36 skipping to change at page 14, line 36
o Most single ISP cases in above examples. o Most single ISP cases in above examples.
z=N: Multihomed mobile networks with multiple MNPs z=N: Multihomed mobile networks with multiple MNPs
o Most multiple ISP cases in above examples. o Most multiple ISP cases in above examples.
o Example: a car with a prefix taken from home (personal traffic o Example: a car with a prefix taken from home (personal traffic
transit on this prefix and is paid by the owner) and one that transit on this prefix and is paid by the owner) and one that
belongs to the car manufacturer (maintenance traffic is paid by belongs to the car manufacturer (maintenance traffic is paid by
the car-manufacturer). This will typically be a (1,1,n) or a the car manufacturer). This will typically be a (1,1,n) or a
(1,n,n,) configuration. (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 started 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
skipping to change at page 16, line 19 skipping to change at page 16, line 19
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 and each issue, potential ways to solve the problem are investigated.
an a recommendation is made on which IETF WG(s) should look into
these issues.
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 [9] 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
skipping to change at page 19, line 7 skipping to change at page 18, line 51
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 needs only to involve
the HA and the MRs. This is a NEMO/MIPv6 specific issue. the HA 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 each other. 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 for those
cases that selecting a different prefix result in a change of cases that selecting a different prefix result in a change of
path, the Shim6 protocols (such as [9]) may be useful. The other path, the Shim6 protocols (such as [9]) may be useful. The other
cases, are NEMO specific. 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
skipping to change at page 31, line 37 skipping to change at page 31, line 37
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
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 is a contribution from The initial evaluation of NEMO Basic Support on multihoming
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-05 (work in progress),
October 2005. October 2005.
[2] Manner, J. and M. Kojo, "Mobility Related Terminology", [2] Manner, J. and M. Kojo, "Mobility Related Terminology",
skipping to change at page 32, line 31 skipping to change at page 32, line 31
"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., "Motivations and Scenarios for Using Multiple
Interfaces and Global Addresses", Interfaces and Global Addresses",
draft-ietf-monami6-multihoming-motivations-scenarios-00 (work draft-ietf-monami6-multihoming-motivation-scenario-00 (work in
in progress), February 2006. progress), February 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-03 (work in progress),
December 2005. December 2005.
skipping to change at page 34, line 12 skipping to change at page 34, line 12
[23] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix [23] 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", [24] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO",
draft-droms-nemo-dhcpv6-pd-02 (work in progress), April 2005. draft-droms-nemo-dhcpv6-pd-02 (work in progress), April 2005.
[25] Kniveton, T. and P. Thubert, "Mobile Network Prefix [25] Kniveton, T. and P. Thubert, "Mobile Network Prefix
Delegation", draft-ietf-nemo-prefix-delegation-00 (work in Delegation", draft-ietf-nemo-prefix-delegation-00 (work in
progress), August 2005. progress), August 2005.
[26] Wakikawa, R., Ernst, T., and K. Nagami, "Multiple Care-of [26] Wakikawa, R., "Multiple Care-of Addresses Registration",
Addresses Registration", draft-wakikawa-mobileip-multiplecoa-05 draft-ietf-monami6-multiplecoa-00 (work in progress),
(work in progress), February 2006. June 2006.
[27] Draves, R., "Default Address Selection for Internet Protocol [27] 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", [28] Thubert, P., "Nested Nemo Tree Discovery",
draft-thubert-tree-discovery-02 (work in progress), July 2005. draft-thubert-tree-discovery-02 (work in progress), July 2005.
[29] Kumazawa, M., "Token based Duplicate Network Detection for [29] 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.
skipping to change at page 38, line 15 skipping to change at page 38, line 15
A.2. Problem-Oriented Approach A.2. Problem-Oriented Approach
A third approach is proposed by Pascal Thubert (Cisco System). This A third approach is proposed by Pascal Thubert (Cisco System). This
focused on the problems of multihomed mobile networks rather than the focused on the problems of multihomed mobile networks rather than the
configuration or ownership. With this approach, there is a set of 4 configuration or ownership. With this approach, there is a set of 4
categories based on two orthogonal parameters: the number of HAs, and categories based on two orthogonal parameters: the number of HAs, and
the number of MNPs advertised. Since the two parameters are the number of MNPs advertised. Since the two parameters are
orthogonal, the categories are not mutually exclusive. The four orthogonal, the categories are not mutually exclusive. The four
categories are: categories are:
o Tarzan: Single HA for Different Care-of Addresses of Same MNP o Tarzan: Single HA for Different CoAs of Same MNP
This is the case where one mobile router registers different This is the case where one MR registers different Care-of
Care-of Addresses to the same home agent for the same subnet Addresses to the same HA for the same subnet prefix. This is
prefix. This is equivalent to the case of y=1, i.e. the (1,1,*) equivalent to the case of y=1, i.e. the (1,1,*) mobile network.
mobile network.
o JetSet: Multiple HAs for Different Care-of Addresses of Same MNP o JetSet: Multiple HAs for Different CoAs of Same MNP
This is the case where the mobile router registers different This is the case where the MR registers different Care-of
Care-of Addresses to different home agents for the same subnet Addresses to different HAs for the same subnet prefix. This is
prefix. This is equivalent to the case of y=n, i.e. the (1,n,*) equivalent to the case of y=n, i.e. the (1,n,*) mobile network.
mobile network.
o Shinkansen: Single MNP Advertised by MR(s) o Shinkansen: Single MNP Advertised by MR(s)
This is the case where one MNP is announced by different MRs. This is the case where one MNP is announced by different MRs.
This is equivalent to the case of x=n and z=1, i.e. the (n,*,1) This is equivalent to the case of x=n and z=1, i.e. the (n,*,1)
mobile network. mobile network.
o DoubleBed: Multiple MNPs Advertised by MR(s) o DoubleBed: Multiple MNPs Advertised by MR(s)
This is the case where more than one MNPs are announced by the This is the case where more than one MNPs are announced by the
skipping to change at page 40, line 22 skipping to change at page 40, line 22
alternate route is provided by another MR connected to the mobile alternate route is provided by another MR connected to the mobile
network. We refer to the former case as an alternate route provided network. We refer to the former case as an alternate route provided
by an alternate egress interface, and the latter case as an alternate by an alternate egress interface, and the latter case as an alternate
route provided by an alternate MR. route provided by an alternate MR.
B.2.1. Using Alternate Egress Interface B.2.1. Using Alternate Egress Interface
When an egress interface of a MR loses the connection to the global When an egress interface of a MR loses the connection to the global
Internet, the MR can make use of its alternate egress interface Internet, the MR can make use of its alternate egress interface
should it possess multiple egress interfaces. The most direct way to should it possess multiple egress interfaces. The most direct way to
do so is for the mobile router to send a binding update to the home do so is for the MR to send a binding update to the HA of the failed
agent of the failed interface using the Care-of Address assigned to interface using the CoA assigned to the alternate interface in order
the alternate interface in order to re-establish the bi-directional to re-establish the bi-directional tunneling using the CoA on the
tunneling using the Care-of Address on the alternate egress alternate egress interface. After a successful binding update, the
interface. After a successful binding update, the MR encapsulates MR encapsulates outgoing packets through the bi-directional tunnel
outgoing packets through the bi-directional tunnel using the using the alternate egress interface.
alternate egress interface.
The idea is to use the global address (most likely a Care-of Address) The idea is to use the global address (most likely a CoA) assigned to
assigned to an alternate egress interface as the new (back-up) an alternate egress interface as the new (back-up) CoA of the MR to
Care-of Address of the mobile router to re-establish the bi- re-establish the bi-directional tunneling with its HA.
directional tunneling with its home agent.
B.2.2. Using Alternate Mobile Router B.2.2. Using Alternate Mobile Router
When the MR loses a connection to the global Internet, the MR can When the MR loses a connection to the global Internet, the MR can
utilize a route provided by an alternate MR (if one exists) to re- utilize a route provided by an alternate MR (if one exists) to re-
establish the bi-directional tunnel with its HA. First, the MR has establish the bi-directional tunnel with its HA. First, the MR has
to obtain a Care-of Address from the alternate MR (i.e. attaches to obtain a CoA from the alternate MR (i.e. attaches itself to the
itself to the alternate MR). Next, it sends binding update to its HA alternate MR). Next, it sends binding update to its HA using the CoA
using the Care-of Address obtained from the alternate MR. From then obtained from the alternate MR. From then on, the MR can
on, the MR can encapsulates outgoing packets through the bi- encapsulates outgoing packets through the bi-directional tunnel using
directional tunnel using via the alternate MR. via the alternate MR.
The idea is to obtain a Care-of Address from the alternate MR and use The idea is to obtain a CoA from the alternate MR and use this as the
this as the new (back-up) Care-of Address of the MR to re-establish new (back-up) CoA of the MR to re-establish the bi-directional
the bi-directional tunneling with its HA. tunneling with its HA.
Note that every packet sent between MNNs and their correspondent Note that every packet sent between MNNs and their correspondent
nodes will experience two levels of encapsulation. First level of nodes will experience two levels of encapsulation. First level of
tunneling occurs between a MR which the MNN uses as its default tunneling occurs between a MR which the MNN uses as its default
router and the MR's HA. The second level of tunneling occurs between router and the MR's HA. The second level of tunneling occurs between
the alternate MR and its HA. the alternate MR and its HA.
B.3. To Avoid Tunneling Loop B.3. To Avoid Tunneling Loop
The method of re-establishing the bi-directional tunnel as described The method of re-establishing the bi-directional tunnel as described
skipping to change at page 42, line 13 skipping to change at page 42, line 13
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 This draft is an update of draft-ng-nemo-multihoming-issues-03.txt
which is itself a merge of 3 previous drafts which is itself a merge of 3 previous drafts
draft-ng-nemo-multihoming-issues-02.txt, draft-ng-nemo-multihoming-issues-02.txt,
draft-eun-nemo-multihoming-problem-statement-00.txt, and draft-eun-nemo-multihoming-problem-statement-00.txt, and
draft-charbon-nemo-multihoming-evaluation-00.txt draft-charbon-nemo-multihoming-evaluation-00.txt
o Changes from draft-ietf-nemo-multihoming-issues-05 to -06:
* 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"
* Re-phrase statements in Sect 4 and 5 where we "... recommend * Re-phrase statements in Sect 4 and 5 where we "... recommend
issue XXX to be worked on by Monami6/Shim6/IPv6/DNA WG" to issue XXX to be worked on by Monami6/Shim6/IPv6/DNA WG" to
instead suggest that solution to the issue be solicited instead suggest that solution to the issue be solicited
elsewhere within the IETF. elsewhere within the IETF.
skipping to change at page 45, line 30 skipping to change at page 45, line 30
17 Woomyeon-dong, Seocho-gu 17 Woomyeon-dong, Seocho-gu
Seoul 137-792 Seoul 137-792
Korea Korea
Phone: +82-2-526-5233 Phone: +82-2-526-5233
Fax: +82-2-526-5200 Fax: +82-2-526-5200
Email: euna@kt.co.kr Email: euna@kt.co.kr
URI: http://mmlab.snu.ac.kr/~eun/ URI: http://mmlab.snu.ac.kr/~eun/
Thierry Ernst Thierry Ernst
Keio University / WIDE INRIA
Jun Murai Lab., Keio University. INRIA Rocquencourt
K-square Town Campus, 1488-8 Ogura, Saiwa-Ku Domaine de Voluceau B.P. 105
Kawasaki, Kanagawa 212-0054 Le Chesnay, 78153
Japan France
Phone: +81-44-580-1600 Phone: +33-1-39-63-59-30
Fax: +81-44-580-1437 Fax: +33-1-39-63-54-91
Email: ernst@sfc.wide.ad.jp Email: thierry.ernst@inria.fr
URI: http://www.sfc.wide.ad.jp/~ernst/ URI: http://www.nautilus6.org/~thierry
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
 End of changes. 39 change blocks. 
89 lines changed or deleted 84 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/