draft-ietf-nemo-multihoming-issues-04.txt   draft-ietf-nemo-multihoming-issues-05.txt 
NEMO Working Group C. Ng NEMO Working Group C. Ng
Internet-Draft Panasonic Singapore Labs Internet-Draft Panasonic Singapore Labs
Expires: April 27, 2006 E. Paik Expires: August 27, 2006 E. Paik
KT KT
T. Ernst T. Ernst
Keio University / WIDE Keio University / WIDE
M. Bagnulo M. Bagnulo
UC3M UC3M
October 24, 2005 February 23, 2006
Analysis of Multihoming in Network Mobility Support Analysis of Multihoming in Network Mobility Support
draft-ietf-nemo-multihoming-issues-04 draft-ietf-nemo-multihoming-issues-05
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 April 27, 2006. This Internet-Draft will expire on August 27, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). 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). Issues are classified according to the Working Group which Support). Recommendations are then made as to whether the NEMO
is the best chartered to solve them. Working Group should solve these issues, or a solution should be
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 . . . . . . . 7 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 . . . . . 8 2.4. (1,n,n): Single MR, Multiple HAs, Multiple MNPs . . . . . 9
2.5. (n,1,1): Multiple MRs, Single HA, Single MNP . . . . . . . 9 2.5. (n,1,1): Multiple MRs, Single HA, Single MNP . . . . . . . 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 . . . . . 10 2.7. (n,n,1): Multiple MRs, Multiple HAs, Single MNP . . . . . 11
2.8. (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs . . . . 11 2.8. (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs . . . . 12
3. Deployment Scenarios and Prerequisites . . . . . . . . . . . . 12 3. Deployment Scenarios and Prerequisites . . . . . . . . . . . . 13
3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 12 3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 13
3.2. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 13 3.2. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 15
4. Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 15 4. Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 15 4.1. Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 16
4.1.1. Failure Detection . . . . . . . . . . . . . . . . . . 15 4.1.1. Failure Detection . . . . . . . . . . . . . . . . . . 16
4.1.2. Path Exploration . . . . . . . . . . . . . . . . . . . 17 4.1.2. Path Exploration . . . . . . . . . . . . . . . . . . . 18
4.1.3. Path Selection . . . . . . . . . . . . . . . . . . . . 18 4.1.3. Path Selection . . . . . . . . . . . . . . . . . . . . 19
4.1.4. Re-Homing . . . . . . . . . . . . . . . . . . . . . . 20 4.1.4. Re-Homing . . . . . . . . . . . . . . . . . . . . . . 21
4.2. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 20 4.2. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 21
4.3. HA Synchronization . . . . . . . . . . . . . . . . . . . . 22 4.3. HA Synchronization . . . . . . . . . . . . . . . . . . . . 23
4.4. MR Synchronization . . . . . . . . . . . . . . . . . . . . 22 4.4. MR Synchronization . . . . . . . . . . . . . . . . . . . . 24
4.5. Prefix Delegation . . . . . . . . . . . . . . . . . . . . 23 4.5. Prefix Delegation . . . . . . . . . . . . . . . . . . . . 24
4.6. Multiple Bindings/Registrations . . . . . . . . . . . . . 23 4.6. Multiple Bindings/Registrations . . . . . . . . . . . . . 25
4.7. Source Address Selection . . . . . . . . . . . . . . . . . 24 4.7. Source Address Selection . . . . . . . . . . . . . . . . . 25
4.8. Loop Prevention in Nested Mobile Networks . . . . . . . . 24 4.8. Loop Prevention in Nested Mobile Networks . . . . . . . . 26
4.9. Prefix Ownership . . . . . . . . . . . . . . . . . . . . . 24 4.9. Prefix Ownership . . . . . . . . . . . . . . . . . . . . . 26
4.10. Preference Settings . . . . . . . . . . . . . . . . . . . 25 4.10. Preference Settings . . . . . . . . . . . . . . . . . . . 26
5. Recommendations to the Working Group . . . . . . . . . . . . . 26 5. Recommendations to the Working Group . . . . . . . . . . . . . 28
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Normative References . . . . . . . . . . . . . . . . . . . 30 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
10.2. Informative References . . . . . . . . . . . . . . . . . . 30 10.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Alternative Classifications Approach . . . . . . . . 33 Appendix A. Alternative Classifications Approach . . . . . . . . 35
A.1. Ownership-Oriented Approach . . . . . . . . . . . . . . . 33 A.1. Ownership-Oriented Approach . . . . . . . . . . . . . . . 35
A.1.1. ISP Model . . . . . . . . . . . . . . . . . . . . . . 33 A.1.1. ISP Model . . . . . . . . . . . . . . . . . . . . . . 35
A.1.2. Subscriber/Provider Model . . . . . . . . . . . . . . 34 A.1.2. Subscriber/Provider Model . . . . . . . . . . . . . . 36
A.2. Problem-Oriented Approach . . . . . . . . . . . . . . . . 36 A.2. Problem-Oriented Approach . . . . . . . . . . . . . . . . 38
Appendix B. Nested Tunneling for Fault Tolerance . . . . . . . . 37 Appendix B. Nested Tunneling for Fault Tolerance . . . . . . . . 39
B.1. Detecting Presence of Alternate Routes . . . . . . . . . . 37 B.1. Detecting Presence of Alternate Routes . . . . . . . . . . 39
B.2. Re-Establishment of Bi-Directional Tunnels . . . . . . . . 38 B.2. Re-Establishment of Bi-Directional Tunnels . . . . . . . . 40
B.2.1. Using Alternate Egress Interface . . . . . . . . . . . 38 B.2.1. Using Alternate Egress Interface . . . . . . . . . . . 40
B.2.2. Using Alternate Mobile Router . . . . . . . . . . . . 38 B.2.2. Using Alternate Mobile Router . . . . . . . . . . . . 40
B.3. To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . 39 B.3. To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . 41
B.4. Points of Considerations . . . . . . . . . . . . . . . . . 39 B.4. Points of Considerations . . . . . . . . . . . . . . . . . 41
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 40 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . . . . 44 Intellectual Property and Copyright Statements . . . . . . . . . . 46
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 basically solves the problem by setting up bi-directional tunnels
skipping to change at page 7, line 13 skipping to change at page 7, line 13
multiple interfaces. In such a case, the MR would have multiple Home multiple interfaces. In such a case, the MR would have multiple Home
Address / Care-of Address pairs. Issues pertaining to a multihomed Address / Care-of Address pairs. Issues pertaining to a multihomed
MR are also addressed in [7]. In addition, the readers should also MR are also addressed in [7]. In addition, the readers should also
keep in mind that when "MNP(s) is/are available in the NEMO", the keep in mind that when "MNP(s) is/are available in the NEMO", the
MNP(s) may either be explicitly announced by the MR via router MNP(s) may either be explicitly announced by the MR via router
advertisement, or made available through Dynamic Host Configuration advertisement, or made 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) mobile network 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, or o The MR has multiple interfaces and thus its has multiple CoAs;
o Multiple global prefixes are available on the visited link, or o Multiple global prefixes are available on the visited link, and
thus it has multiple CoAs; or
o Multiple global prefixes are available on the home link (Note that o Multiple global prefixes are available on the home link, and thus
in this case, those prefixes are not all available in the NEMO, the MR has more than one path to reach the home agent.
since there is only a single MNP in the NEMO)
Note that the case where multiple prefixes are available on the
visited link does not have any bearing on the MNPs. MNPs are
independent of prefixes available on the link where MR is attached,
thus prefixes available on the foreign link are not announced 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
configured to do so. In this configuration, only one MNP is
announced.
A bi-directional tunnel would then be established between each pair A bi-directional tunnel would then be established between each pair
of Home Address / Care-of Address. of Home Address / Care-of Address.
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) mobile network 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 be itself 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. pair of Home Address / Care-of Address.
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) mobile network 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 Home Address, 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 pair of
Home Address / Care-of Address. Home Address / Care-of Address.
Regarding MNNs, they are (usually) not multihomed since they would Regarding MNNs, they are (usually) not multihomed since they would
skipping to change at page 8, line 51 skipping to change at page 9, line 21
_ |-|_|=| |_____|-| _ _ |-|_|=| |_____|-| _
|_|-| | | _ |-|_| |_|-| | | _ |-|_|
|-|_|-| |-|_|-|
| |
MNNs MR AR Internet AR HA1 MNNs MR AR Internet AR HA1
Figure 3: (1,n,1): 1 MR, multiple HAs, 1 MNP Figure 3: (1,n,1): 1 MR, multiple HAs, 1 MNP
2.4. (1,n,n): Single MR, Multiple HAs, Multiple MNPs 2.4. (1,n,n): Single MR, Multiple HAs, Multiple MNPs
The (1,n,n) mobile network has only one MR. However, the MR is The (1,n,n) 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 pair of Home Address /
Care-of Address. Care-of Address.
Regarding MNNs, they are generally multihomed since they would Regarding MNNs, they are generally multihomed since they would
skipping to change at page 9, line 30 skipping to change at page 10, line 7
|_|-|<-_ |-|_|-| | _ |_|-|<-_ |-|_|-| | _
_ |-|_|=| |_____|-| _ |-|_| _ |-|_|=| |_____|-| _ |-|_|
|_|-| | |-|_|-| |_|-| | |-|_|-|
| | | |
MNNs MR AR Internet AR HA1 MNNs MR AR Internet AR HA1
Figure 4: (1,n,n): 1 MR, multiple HAs, multiple MNPs Figure 4: (1,n,n): 1 MR, multiple HAs, multiple MNPs
2.5. (n,1,1): Multiple MRs, Single HA, Single MNP 2.5. (n,1,1): Multiple MRs, Single HA, Single MNP
The (n,1,1) mobile network has more than one MR advertising global The (n,1,1) 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 pair of
Home Address / Care-of Address. Home Address / Care-of Address.
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
skipping to change at page 10, line 19 skipping to change at page 10, line 34
_ | | |-| _ _ | | |-| _
|_|-| _ |-|_____| | _ |-|_| |_|-| _ |-|_____| | _ |-|_|
|-|_|-| |-|_|-| |-|_|-| |-|_|-|
p<- | | p<- | |
MNNs MR1 Internet AR HA MNNs MR1 Internet AR HA
Figure 5: (n,1,1): Multiple MRs, 1 HA, 1 MNP Figure 5: (n,1,1): Multiple MRs, 1 HA, 1 MNP
2.6. (n,1,n): Multiple MRs, Single HA, Multiple MNPs 2.6. (n,1,n): Multiple MRs, Single HA, Multiple MNPs
The (n,1,n) mobile network has more than one MR; multiple global The (n,1,n) 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 pair of
Home Address / Care-of Address. Home Address / 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
skipping to change at page 10, line 46 skipping to change at page 11, line 19
_ | | |-| _ _ | | |-| _
|_|-| _ |-|_____| | _ |-|_| |_|-| _ |-|_____| | _ |-|_|
|-|_|-| |-|_|-| |-|_|-| |-|_|-|
p1<- | | p1<- | |
MNNs MR1 Internet AR HA MNNs MR1 Internet AR HA
Figure 6: (n,1,n): Multiple MRs, 1 HA, multiple MNPs Figure 6: (n,1,n): Multiple MRs, 1 HA, multiple MNPs
2.7. (n,n,1): Multiple MRs, Multiple HAs, Single MNP 2.7. (n,n,1): Multiple MRs, Multiple HAs, Single MNP
The (n,n,1) mobile network has more than one MR advertising multiple The (n,n,1) 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 pair of Home Address / Care-of Address.
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
skipping to change at page 11, line 26 skipping to change at page 12, line 7
|_|-| _ |-|_____|-| _ |_|-| _ |-|_____|-| _
|-|_|-| | _ |-|_| |-|_|-| | _ |-|_|
<- | |-|_|-| <- | |-|_|-|
p | p |
MNNs MR1 Internet AR HA1 MNNs MR1 Internet AR HA1
Figure 7: (n,n,1): Multiple MRs, Multiple HAs, 1 MNP Figure 7: (n,n,1): Multiple MRs, Multiple HAs, 1 MNP
2.8. (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs 2.8. (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs
The (n,n,n) mobile network has multiple MRs advertising different The (n,n,n) 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 pair of Home Address / 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
skipping to change at page 12, line 41 skipping to change at page 13, line 41
802.11 and GPRS capabilities). This is a (1,1,*) if both 802.11 and GPRS capabilities). This is a (1,1,*) if both
accesses are subscribed to the same ISP. If the two accesses accesses are subscribed to the same ISP. If the two accesses
are offered by independent ISPs, this is a (1,n,n) are offered by independent ISPs, this is a (1,n,n)
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: a train with one MR in each car, all served by the
same HA, thus a (n,1,*). Alternatively, the train company same HA, thus a (n,1,*) configuration. Alternatively, the
might be forced to use different ISPs when the train go to train company might be forced to use different ISPs when the
different locations, thus it is a (n,n,n). train go to different locations, thus it is a (n,n,n)
configuration.
Benefits: Load Sharing, Reliability, Ubiquitous Access, Benefits: Load Sharing, Reliability, Ubiquitous Access,
Aggregate Bandwidth Aggregate Bandwidth
o Example 2: W-PAN with a GPRS-enabled phone and a WiFi-enabled o Example 2: W-PAN with a GPRS-enabled phone and a WiFi-enabled
PDA. This is a (n,n,n) if the two access technologies are PDA. This is a (n,n,n) configuration if the two access
subscribed separately. 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 Most single ISP cases in above examples.
y=N: Multihomed mobile networks with multiple HAs y=N: Multihomed mobile networks with multiple HAs
o Most multiple ISP cases in above examples. o Most multiple ISP cases in above examples.
o Example: a transatlantic flight with a HA in each continent. o Example: a transatlantic flight with a HA in each continent.
This is a (1,n,1) network if there is only one MR. This is a (1,n,1) configuration if there is only one MR.
Benefits: Ubiquity, Preferences (reduced delay, shortest path), Benefits: Ubiquity, Preferences (reduced delay, shortest path),
Reliability Reliability
z=1: Multihomed mobile networks with a single MNP z=1: Multihomed mobile networks with a single MNP
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,). (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
time between the mobile network and the fixed network to meet all time between the mobile network and the fixed network to meet all
skipping to change at page 14, line 37 skipping to change at page 15, line 47
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 for the administration of the 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
have an increase in the total aggregated bandwidth available to increase the total aggregated bandwidth available to the mobile
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
skipping to change at page 19, line 44 skipping to change at page 20, line 44
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
priority). This questions which of the bi-directional tunnels would priority). This questions which of the bi-directional tunnels would
be selected, and based on which of the parameters (e.g. type of flow be selected, and based on which of the parameters (e.g. type of flow
that goes into/out of the mobile network). that goes into/out of the mobile network).
The mechanisms for the selection among the different tunnels between The mechanisms for the selection among the different tunnels between
the MR(s) and the HA(s) seems to be quite NEMO/MIPv6 specific. For the MR(s) and the HA(s) seems to be quite NEMO/MIPv6 specific.
(1,*,*) cases, they are no different from the case of path selection
between a mobile host and its HA(s). As such, a solution for MIPv6 For (1,*,*) cases, they are no different from the case of path
should apply to NEMO as well. For the case of (n,*,*), a MR 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
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. The mechanisms for selecting among different functionality for NEMO.
end-to-end paths based on address selection are similar to the ones
used in other multihoming scenarios, as those considered by Shim6 The mechanisms for selecting among different end-to-end paths based
(e.g. [16]). on address selection are similar to the ones used in other
multihoming scenarios, as those considered by Shim6 (e.g. [16]).
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
skipping to change at page 20, line 43 skipping to change at page 21, line 45
MNP is tunnelled to a home agent that does not handle that specific MNP is tunnelled to a home agent that does not handle that specific
MNP the packet may be discarded either by the home agent or by a MNP the packet may be discarded either by the home agent or by a
border gateway in the home network. border gateway 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,n) cases, there is not such a problem, since there is o For the (1,1,*) and (n,1,1) cases, there is not such a problem,
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
the HA, it may occur at the MRs, when each MR is handling
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 The more complex case is the (n,n,n) case. A simplified case
occurs when all the prefixes are accepted by all the HAs, so that occurs when all the prefixes are accepted by all the HAs, so that
no problems occur with the ingress filtering. However, this no problems occur with the ingress filtering. However, this
cannot be always assumed, resulting in the problem described cannot be always assumed, resulting in the problem described
below. 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
skipping to change at page 22, line 17 skipping to change at page 23, line 24
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 (eg. see [19]).
4.3. HA Synchronization 4.3. HA Synchronization
In the (*,n,*) mobile networks, 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 [20] and
[21]. Such synchronization might also be necessary in a (*,n,*) [21]. Such synchronization might also be necessary in a (*,n,*)
mobile network, when a MR sends binding update messages to only one configuration, when a MR sends binding update messages to only one HA
HA (instead of all HAs). In such cases, the binding update (instead of all HAs). In such cases, the binding update information
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 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. It is dealt with by Mobile IPv6 as well as NEMO Basic Support.
recommended that the Monami6 WG take this issue into consideration.
4.4. MR Synchronization 4.4. MR Synchronization
In the (n,*,*) mobile network, different MRs may need to be In the (n,*,*) configurations, there are common decisions which may
synchronized in order to take common decisions, such as: require synchronization among different MRs [22], such as:
o advertising the same MNP in the (n,*,1) mobile network (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) mobile network; 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,*,*) mobile network. in the (n,*,*) configuration.
However, there is no known standardized protocols for this kind of However, there is no known standardized protocols for this kind of
router-to-router synchronization. Without such synchronization, it router-to-router synchronization. Without such synchronization, it
may not be possible for a (n,*,*) mobile network to achieve various may not be possible for a (n,*,*) configuration to achieve various
multihoming goals, such as fault tolerance. multihoming goals, such as fault tolerance.
Such a synchronization mechanism can be primary-secondary (i.e. a Such a synchronization mechanism can be primary-secondary (i.e. a
master MR, with the other MRs as backup) or peer-to-peer (i.e. there master MR, with the other MRs as backup) or peer-to-peer (i.e. there
is no clear administrative hierarchy between the MRs). The need for is no clear administrative hierarchy between the MRs). The need for
such mechanism is general in the sense that a multi-router site in such mechanism is general in the sense that a multi-router site in
the fixed network would require the same level of router the fixed network would require the same level of router
synchronization. It is recommended that the issue be looked at in synchronization.
the IPv6 or Shim6 WG, and the NEMO WG to contribute any NEMO specific
requirement. Thus, this issue is not specific to NEMO Basic Support, though there
is a more pressing need to develop a MR to MR synchronization scheme
for proving fault tolerances and failure recovery in NEMO
configurations due to the higher possibility of links failure.
In conclusion it is recommended to investigate a generic solution to
this issue although the solution would first have to be developed for
NEMO deployments.
4.5. Prefix Delegation 4.5. Prefix Delegation
In the (*,*,1) mobile network, the same MNP must be advertised to the In the (*,*,1) configurations, the same MNP must be advertised to the
MNNs through different paths. There is, however, no synchronization MNNs through different paths. There is, however, no synchronization
mechanism available to achieve this. Particularly, mechanism available to achieve this. Without a synchronization
mechanism, MR may end up announcing incompatible MNPs. Particularly,
o for the (*,n,1) mobile network, how can multiple HAs delegate the o for the (*,n,1) cases, how can multiple HAs delegate the same MNP
same MNP to the mobile network? For doing so, the HAs may be to the mobile network? For doing so, the HAs may be somehow
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) mobile network, how can multiple MRs be o for the (n,*,1) cases, how can multiple MRs be synchronized to
synchronized to advertise the same MNP down the NEMO-link? For advertise the same MNP down the NEMO-link? For doing so, the MRs
doing so, the MRs may be somehow configured to advertise the same may be somehow configured to advertise the same MNP (see also "MR
MNP (see also "MR Synchronization" in Section 4.4). Synchronization" in Section 4.4).
Prefix delegation mechanisms [22][23][24] could be used to ensure all Prefix delegation mechanisms [23][24][25] could be used to ensure all
routers advertise the same MNP. The WG should consider their routers advertise the same MNP. Their application to a multihomed
application to a multihomed mobile network. 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 [25] can solve this for both Mobile IPv6 to note that solutions like [26] can solve this for both Mobile IPv6
and NEMO Basic Support. This issue should be 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) mobile networks, MNNs would be configured with In the (*,*,n) configurations, MNNs would be configured with multiple
multiple addresses. Source address selection mechanisms are needed addresses. Source address selection mechanisms are needed to decide
to decide which address to choose from. In addition, source address which address to choose from.
selection may be closely related to path selection procedures (see
Section 4.1.3) and re-homing techniques (see Section 4.1.4).
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 [26] to be used. Further mechanisms such as those specified in [27] 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. prove to be useful. Note that source address selection may be
closely related to path selection procedures (see Section 4.1.3) and
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. It is recommended that the issue be examined by other WG prefixes.
(such as IPv6).
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. As the aggregated network no longer forms a simple tree structure. In
such, a solution to prevent an infinite loop of multiple mobile such a situation, infinite loop within the mobile network may occur.
routers must be provided.
This problem is specific to NEMO Basic Support. It is recommended This problem is specific to NEMO Basic Support. However, at the time
that the NEMO WG standardizes a solution to solve this problem (such of writing, more research is recommended to assess the probability of
as the use of a tree-spanning algorithm, or [27]). loops occurring in a multihomed mobile network. For related work,
see [28] 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 [28]. A possible approach to solving this problem is described in [29].
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. It is recommended that the NEMO WG standardizes a problem to occur.
solution to solve this problem if there is sufficient vendor/operator
interest, or specifies that the split of a (n,*,1) network cannot be It is recommended that the NEMO WG standardizes a solution to solve
allowed without a router renumbering. this problem if there is sufficient vendor/operator interest, or
specifies that the split of a (n,*,1) network cannot be allowed
without a router renumbering.
4.10. Preference Settings 4.10. Preference Settings
When a mobile network is multihomed, the MNNs may be able to enjoy When a mobile network is multihomed, the MNNs may be able to benefit
the benefits of multihoming, such as to choose among the available from this configuration, such as to choose among the available paths
paths based on cost, transmission delays, bandwidth, etc. However, based on cost, transmission delays, bandwidth, etc. However, in some
in some cases, such a choice is not made available to the MNNs. cases, such a choice is not made available to the MNNs.
Particularly, Particularly:
o In the (*,*,n) mobile network, the MNNs can influence the path by o In the (*,*,n) configuration, the MNNs can influence the path by
source address selection (see Section 4.1.3, Section 4.7). source address selection (see Section 4.1.3, Section 4.7).
o In the (n,*,*) mobile network, the MNNs can influence the path by o In the (n,*,*) configuration, the MNNs can influence the path by
default router selection (see Section 4.1.3). default router selection (see Section 4.1.3).
o In the (1,*,1) mobile network, the MNNs cannot influence the path o In the (1,*,1) configuration, the MNNs cannot influence the path
selection. selection.
A mechanism that allows the MNN to indicate its preference for a A mechanism that allows the MNN to indicate its preference for a
given traffic might be helpful. In addition, there may also be a given traffic might be helpful. In addition, there may also be a
need to exchange some information between the MRs and the MNNs. This need to exchange some information between the MRs and the MNNs. This
problem is general in the sense that any IPv6 nodes may wish to problem is general in the sense that any IPv6 nodes may wish to
influence the routing decision done by the upstream routers. Such influence the routing decision done by the upstream routers. Such
mechanism is currently being explored by various WGs, such as the mechanism is currently being explored by various WGs, such as the
NSIS and IPFIX WGs. It is also possible that a Shim6 layer in the NSIS and IPFIX WGs. It is also possible that a Shim6 layer in the
MNNs may possess such capability. It is recommended that vendors or MNNs may possess such capability.
operators to investigate into the solutions developed by these WGs
when providing multihoming capabilities to mobile networks. It is recommended that vendors or operators to investigate into the
solutions developed by these WGs when providing multihoming
capabilities to mobile networks.
5. Recommendations to the Working Group 5. Recommendations to the Working Group
Several issues that might impact the deployment of NEMO with Several issues that might impact the deployment of NEMO with
multihoming capabilities were identified in Section 4. These are multihoming capabilities were identified in Section 4. These are
shown in the matrix below, for each of the eight multihoming shown in the matrix below, for each of the eight multihoming
configurations, together with indications of the WG(s) in which each configurations, together with indications of from which WG(s) a
issue is the most likely to be solved. solution to each issue is most likely to be found.
+=================================================================+ +=================================================================+
| # 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 |
+---------------------------------+---+---+---+---+---+---+---+---+ +---------------------------------+---+---+---+---+---+---+---+---+
skipping to change at page 27, line 5 skipping to change at page 29, line 5
| 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 concern other Working Groups. The readers are reminded and which are not. The readers are reminded that this matrix is a
that this matrix is a simplification of Section 4 as subtle details simplification of Section 4 as subtle details are not represented in
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 Failure Detection, Path Exploration, Path Selection, and Re-Homing o A solution for Failure Detection, Path Exploration, Path
be worked on by the Monami6 WG 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 that such issues be taken into nodes. As such, we would recommend vendors to solicit a solution
consideration by the Monami6 WG. In addition, a Shim6 mechanism for these issues from other WGs in the IETF, for instance the
is expected to be useful for the issues of Path Selection and Re- Monami6 or Shim6 WG.
Homing. It is thus our recommendation that the NEMO WG would re-
evaluate the applicability of mechanisms developed by the Shim6
and Monami6 WGs when they are available.
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) NEMO can be envisioned on vehicles for Deployment of the (n,n,n) configuration can be envisioned on
mass transportation (such as buses, trains) where different vehicles for mass transportation (such as buses, trains) where
service providers may install their own mobile routers on the different service providers may install their own mobile routers
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 that 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 Home Agent Synchronization and Multiple Bindings/Registrations be o A solution for Home Agent Synchronization be looked at in a
worked on by the Monami6 WG mobility specific WG and taking into consideration both mobile
hosts operating Mobile IPv6 and mobile routers operating NEMO
Basic Support.
These are problems that will be addressed by the Monami6 WG, and o A solution for Multiple Bindings/Registrations be presently looked
it is believed that a solution that applies to mobile hosts would at by the Monami6 WG.
applies to mobile routers running the NEMO Basic Support protocol.
o Prefix Delegation be reviewed and checked by the NEMO WG o Prefix Delegation be reviewed and checked by the NEMO WG
There is already a WG draft providing prefix delegation There are already WG drafts and [30] providing prefix delegation
functionality to NEMO Basic Support. The WG should review the functionality to NEMO Basic Support. The WG should review these
draft and verified that it addresses any concern a multihomed NEMO drafts and verified that they address any concern a multihomed
might have, as discussed in Section 4.5. NEMO might have, as discussed in Section 4.5.
o Loop Prevention in Nested NEMO be worked on by the NEMO WG o Loop Prevention in Nested NEMO be investigated
Having a loop in nested NEMO is a real and serious problem, Further research is recommended to assess the risk of having a
especially when connections are wireless (therefore there is no loop in the nesting of multihomed mobile networks.
physical structure to avoid loops).
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
skipping to change at page 30, line 17 skipping to change at page 32, line 17
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",
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-04 (work in progress), October 2005. draft-ietf-nemo-terminology-05 (work in progress),
February 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., Montavont, N., Wakikawa, R., Paik, E., Ng, C., [6] Ernst, T., "Motivations and Scenarios for Using Multiple
Kuladinithi, K., and T. Noel, "Goals and Benefits of Interfaces and Global Addresses",
Multihoming", draft-multihoming-generic-goals-and-benefits-02 draft-ietf-monami6-multihoming-motivations-scenarios-00 (work
(work in progress), October 2005. in 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-montavont-mobileip-multihoming-pb-statement-05 (work in draft-ietf-monami6-mipv6-analysis-00 (work in progress),
progress), October 2005. February 2006.
[8] Arkko, J., "Failure Detection and Locator Pair Exploration [8] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair
Design for IPv6 Multihoming", Exploration Protocol for IPv6 Multihoming",
draft-ietf-shim6-failure-detection-01 (work in progress), draft-ietf-shim6-failure-detection-03 (work in progress),
October 2005. December 2005.
[9] Beijnum, I., "Shim6 Reachability Detection", [9] Beijnum, I., "Shim6 Reachability Detection",
draft-ietf-shim6-reach-detect-00 (work in progress), July 2005. draft-ietf-shim6-reach-detect-01 (work in progress),
October 2005.
[10] Yegin, A., "Link-layer Event Notifications for Detecting [10] Yegin, A., "Link-layer Event Notifications for Detecting
Network Attachments", draft-ietf-dna-link-information-02 (work Network Attachments", draft-ietf-dna-link-information-03 (work
in progress), July 2005. in progress), October 2005.
[11] Narayanan, S., "Detecting Network Attachment in IPv6 - Best [11] Narayanan, S., "Detecting Network Attachment in IPv6 - Best
Current Practices for hosts.", draft-ietf-dna-hosts-01 (work in Current Practices for hosts.", draft-ietf-dna-hosts-02 (work in
progress), July 2005. progress), October 2005.
[12] Yegin, A., "Link-layer Hints for Detecting Network [12] Yegin, A., "Link-layer Hints for Detecting Network
Attachments", draft-yegin-dna-l2-hints-01 (work in progress), Attachments", draft-yegin-dna-l2-hints-01 (work in progress),
February 2004. February 2004.
[13] Yegin, A., "Supporting Optimized Handover for IP Mobility [13] Yegin, A., "Supporting Optimized Handover for IP Mobility
-Requirements for Underlying Systems", -Requirements for Underlying Systems",
draft-manyfolks-l2-mobilereq-02 (work in progress), July 2002. draft-manyfolks-l2-mobilereq-02 (work in progress), July 2002.
[14] Narayanan, S., "Detecting Network Attachment in IPv6 - Best [14] Narayanan, S., "Detecting Network Attachment in IPv6 - Best
Current Practices for Routers", draft-ietf-dna-routers-00 (work Current Practices for Routers", draft-ietf-dna-routers-01 (work
in progress), July 2005. in progress), October 2005.
[15] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [15] 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 [16] Bagnulo, M. and J. Arkko, "Functional decomposition of the
multihoming protocol", draft-ietf-shim6-functional-dec-00 (work multihoming protocol", draft-ietf-shim6-functional-dec-00 (work
in progress), July 2005. in progress), July 2005.
[17] Ferguson, P. and D. Senie, "Network Ingress Filtering: [17] 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
skipping to change at page 31, line 43 skipping to change at page 33, line 45
(work in progress), September 2005. (work in progress), September 2005.
[20] Wakikawa, R., Devarapalli, V., and P. Thubert, "Inter Home [20] 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 [21] 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] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix [22] Tsukada, M., "Analysis of Multiple Mobile Routers Cooperation",
draft-tsukada-nemo-mr-cooperation-analysis-00 (work in
progress), October 2005.
[23] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
Delegation", RFC 3769, June 2004. Delegation", RFC 3769, June 2004.
[23] 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.
[24] 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.
[25] Wakikawa, R., "Multiple Care-of Addresses Registration", [26] Wakikawa, R., Ernst, T., and K. Nagami, "Multiple Care-of
draft-wakikawa-mobileip-multiplecoa-04 (work in progress), Addresses Registration", draft-wakikawa-mobileip-multiplecoa-05
June 2005. (work in progress), February 2006.
[26] 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.
[27] 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.
[28] 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.
[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 40, 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-04 to -05:
* Addressed Issue #23: modified text in Sect 4.2: "Ingress
Filtering"
* Re-phrase statements in Sect 4 and 5 where we "... recommend
issue XXX to be worked on by Monami6/Shim6/IPv6/DNA WG" to
instead suggest that solution to the issue be solicited
elsewhere within the IETF.
o Changes from draft-ietf-nemo-multihoming-issues-03 to -04: o Changes from draft-ietf-nemo-multihoming-issues-03 to -04:
* Updated Section 3: "Deployment Scenarios and Prerequisites" * Updated Section 3: "Deployment Scenarios and Prerequisites"
* Modifications to Section 4: * Modifications to Section 4:
+ Removed "Media Detection" and moved the relevant concerns to + Removed "Media Detection" and moved the relevant concerns to
"Path Exploration" "Path Exploration"
+ Added new "Preference Settings" issue + Added new "Preference Settings" issue
+ Various text clean-ups in mopst of the sub-sections + Various text clean-ups in most of the sub-sections
* Modifications to Section 5: * Modifications to Section 5:
+ Changed Section 5: "Matrix" to "Recommendations to the + Changed Section 5: "Matrix" to "Recommendations to the
Working Group" Working Group"
+ Identifies which are the issues that are important, and made + Identifies which are the issues that are important, and made
recommendations as to how to resolve these multihoming recommendations as to how to resolve these multihoming
issues issues
* Addressed Issue #12: Added Appendix B.4: "Points of * Addressed Issue #12: Added Appendix B.4: "Points of
Considerations" to document the concerns raised for this tunnel Considerations" to document the concerns raised for this tunnel
re-eatblishment mechanism. re-establishment mechanism.
o Changes from draft-ietf-nemo-multihoming-issues-02 to -03: o Changes from draft-ietf-nemo-multihoming-issues-02 to -03:
* Enlisted Marcelo Bagnulo as co-author * Enlisted Marcelo Bagnulo as co-author
* Restructuring of Section 4: * Restructuring of Section 4:
+ Re-named 'Path Survival' to 'Fault Tolerance' + Re-named 'Path Survival' to 'Fault Tolerance'
+ Moved 'Path Failure Detection' and 'Path Selection' as sub- + Moved 'Path Failure Detection' and 'Path Selection' as sub-
issues of 'Fault Tolerance' issues of 'Fault Tolerance'
+ Added 'Path Exploration' and 'Re-homing' as sub-issues of + Added 'Path Exploration' and 'Re-homing' as sub-issues of
'Fault Tolerance' 'Fault Tolerance'
+ Removed 'Impact on Routing Infrastructure' + Removed 'Impact on Routing Infrastructure'
* Breaking references into Normative and Informative * Breaking references into Normative and Informative
o Changes from draft-ietf-nemo-multihoming-issues-01 to -02: o Changes from draft-ietf-nemo-multihoming-issues-01 to -02:
* Added recommendations/suggestion of which WG each issue should * Added recommendations/suggestion of which WG each issue should
be addressed as pointed out in 61st IETF. be addressed as pointed out in 61st IETF.
* Minor updates on references. * Minor updates on references.
skipping to change at page 44, line 41 skipping to change at page 46, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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 currently provided by the
Internet Society. Internet Society.
 End of changes. 104 change blocks. 
210 lines changed or deleted 256 lines changed or added

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