draft-ietf-nemo-ro-problem-statement-01.txt   draft-ietf-nemo-ro-problem-statement-02.txt 
NEMO Working Group C. Ng NEMO Working Group C. Ng
Internet-Draft Panasonic Singapore Labs Internet-Draft Panasonic Singapore Labs
Expires: April 14, 2006 P. Thubert Expires: July 1, 2006 P. Thubert
Cisco Systems Cisco Systems
M. Watari M. Watari
KDDI R&D Labs KDDI R&D Labs
F. Zhao F. Zhao
UC Davis UC Davis
October 11, 2005 December 28, 2005
Network Mobility Route Optimization Problem Statement Network Mobility Route Optimization Problem Statement
draft-ietf-nemo-ro-problem-statement-01 draft-ietf-nemo-ro-problem-statement-02
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 14, 2006. This Internet-Draft will expire on July 1, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
With current Network Mobility (NEMO) Basic Support, all With current Network Mobility (NEMO) Basic Support, all
communications to and from Mobile Network Nodes must go through the communications to and from Mobile Network Nodes must go through the
bi-directional tunnel established between the Mobile Router and Home bi-directional tunnel established between the Mobile Router and Home
Agent when the mobile network is away. This results in various Agent when the mobile network is away. This sub-optimal routing
inefficiencies associated with packet delivery. This document results in various inefficiencies associated with packet delivery,
investigates such inefficiencies, and provides for the motivation such as increased delay and bottleneck links leading to traffic
behind Route Optimization (RO) for NEMO. congestion, which can ultimately disrupt all communications to and
from the Mobile Network Nodes. Additionally, with nesting of Mobile
Networks, these inefficiencies get compounded, and stalemate
conditions may occur in specific dispositions. This document
investigates such problems, and provides for the motivation behind
Route Optimization (RO) for NEMO.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. NEMO Route Optimization Problem Statement . . . . . . . . . . 4 2. NEMO Route Optimization Problem Statement . . . . . . . . . . 5
2.1. Sub-Optimality with NEMO Basic Support . . . . . . . . . . 4 2.1. Sub-Optimality with NEMO Basic Support . . . . . . . . . . 5
2.2. Bottleneck in Home Network . . . . . . . . . . . . . . . . 6 2.2. Bottleneck in Home Network . . . . . . . . . . . . . . . . 7
2.3. Amplified Sub-Optimality in Nested Mobile Networks . . . . 6 2.3. Amplified Sub-Optimality in Nested Mobile Networks . . . . 7
2.4. Sub-Optimality with Combined Mobile IPv6 Route 2.4. Sub-Optimality with Combined Mobile IPv6 Route
Optimization . . . . . . . . . . . . . . . . . . . . . . . 8 Optimization . . . . . . . . . . . . . . . . . . . . . . . 9
2.5. Security Policy Prohibiting Traffic From Visiting Nodes . 9 2.5. Security Policy Prohibiting Traffic From Visiting Nodes . 10
2.6. Instability of Communications within a Nested Mobile 2.6. Instability of Communications within a Nested Mobile
Network . . . . . . . . . . . . . . . . . . . . . . . . . 9 Network . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7. Stalemate with a Home Agent Nested in a Mobile Network . . 10 2.7. Stalemate with a Home Agent Nested in a Mobile Network . . 11
3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 13 7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 14
7.2. Informative Reference . . . . . . . . . . . . . . . . . . 13 7.2. Informative Reference . . . . . . . . . . . . . . . . . . 14
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15
Appendix B. Various configurations involving Nested Mobile Appendix B. Various configurations involving Nested Mobile
Networks . . . . . . . . . . . . . . . . . . . . . . 15 Networks . . . . . . . . . . . . . . . . . . . . . . 16
B.1. CN located in the fixed infrastructure . . . . . . . . . . 15 B.1. CN located in the fixed infrastructure . . . . . . . . . . 16
B.1.1. Case A: LFN and standard IPv6 CN . . . . . . . . . . . 16 B.1.1. Case A: LFN and standard IPv6 CN . . . . . . . . . . . 17
B.1.2. Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . 16 B.1.2. Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . 17
B.1.3. Case C: VMN and standard IPv6 CN . . . . . . . . . . . 16 B.1.3. Case C: VMN and standard IPv6 CN . . . . . . . . . . . 17
B.2. CN located in distinct nested NEMOs . . . . . . . . . . . 17 B.2. CN located in distinct nested NEMOs . . . . . . . . . . . 18
B.2.1. Case D: LFN and standard IPv6 CN . . . . . . . . . . . 18 B.2.1. Case D: LFN and standard IPv6 CN . . . . . . . . . . . 19
B.2.2. Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . 18 B.2.2. Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . 19
B.2.3. Case F: VMN and standard IPv6 CN . . . . . . . . . . . 18 B.2.3. Case F: VMN and standard IPv6 CN . . . . . . . . . . . 19
B.3. CN and MNN located in the same nested NEMO . . . . . . . . 19 B.3. CN and MNN located in the same nested NEMO . . . . . . . . 20
B.3.1. Case G: LFN and standard IPv6 CN . . . . . . . . . . . 20 B.3.1. Case G: LFN and standard IPv6 CN . . . . . . . . . . . 21
B.3.2. Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . 20 B.3.2. Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . 21
B.3.3. Case I: VMN and standard IPv6 CN . . . . . . . . . . . 21 B.3.3. Case I: VMN and standard IPv6 CN . . . . . . . . . . . 22
B.4. CN located behind the same nested MR . . . . . . . . . . . 21 B.4. CN located behind the same nested MR . . . . . . . . . . . 22
B.4.1. Case J: LFN and standard IPv6 CN . . . . . . . . . . . 22 B.4.1. Case J: LFN and standard IPv6 CN . . . . . . . . . . . 23
B.4.2. Case K: VMN and MIPv6 CN . . . . . . . . . . . . . . . 22 B.4.2. Case K: VMN and MIPv6 CN . . . . . . . . . . . . . . . 23
B.4.3. Case L: VMN and standard IPv6 CN . . . . . . . . . . . 23 B.4.3. Case L: VMN and standard IPv6 CN . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Appendix C. Example of How a Stalemate Situation can Occur . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 29
1. Introduction 1. Introduction
With current Network Mobility (NEMO) Basic Support [1], all With current Network Mobility (NEMO) Basic Support [1], all
communications to and from nodes in a mobile network must go through communications to and from nodes in a mobile network must go through
the bi-directional tunnel established between the Mobile Router and the bi-directional tunnel established between the Mobile Router and
its Home Agent when the mobile network is away. Although such an its Home Agent (also known as the MRHA tunnel) when the mobile
arrangement allows Mobile Network Nodes to reach and be reached by network is away. Although such an arrangement allows Mobile Network
any node on the Internet , limitations associated to the base Nodes to reach and be reached by any node on the Internet,
protocol degrade overall performance of the network, and, ultimately, limitations associated to the base protocol degrade overall
can prevent all communications to and from the Mobile Network Nodes. performance of the network, and, ultimately, can prevent all
communications to and from the Mobile Network Nodes.
Some of these concerns already exist with Mobile IPv6 [4] and were Some of these concerns already exist with Mobile IPv6 [4] and were
addressed by the mechanism known as Route Optimization, which is part addressed by the mechanism known as Route Optimization, which is part
of the base protocol. With Mobile IPv6, Route Optimization mostly of the base protocol. With Mobile IPv6, Route Optimization mostly
improves the end to end path between Mobile Node and Correspondent improves the end to end path between Mobile Node and Correspondent
Node, with an additional benefit of reducing the load of the Home Node, with an additional benefit of reducing the load of the Home
Network, thus its name. Network, thus its name.
NEMO Basic Support presents a number of additional issues, making the NEMO Basic Support presents a number of additional issues, making the
problem more complex, so it was decided to address Route Optimization problem more complex, so it was decided to address Route Optimization
skipping to change at page 4, line 7 skipping to change at page 5, line 7
This document explores limitations inherent in NEMO Basic Support, This document explores limitations inherent in NEMO Basic Support,
and their effects on communications between a Mobile Network Node and and their effects on communications between a Mobile Network Node and
its corresponding peer. This is detailed in Section 2. It is its corresponding peer. This is detailed in Section 2. It is
expected for readers to be familiar with general terminologies expected for readers to be familiar with general terminologies
related to mobility in [4][2], NEMO related terms defined in [3], and related to mobility in [4][2], NEMO related terms defined in [3], and
NEMO goals and requirements [5]. NEMO goals and requirements [5].
2. NEMO Route Optimization Problem Statement 2. NEMO Route Optimization Problem Statement
In essence, the goal of Route Optimization in NEMO is to reduce Given the NEMO Basic Support protocol, all data packets to and from
limitations and sub-optimalities introduced by the bi-directional Mobile Network Nodes must go through the Home Agent, even though a
tunnel between a Mobile Router and its Home Agent (also known as the shorter path may exist between the Mobile Network Node and its
MRHA tunnel). In the following sub-sections, we will describe the Correspondent Node. In addition, with the nesting of Mobile Routers,
effects of sub-optimal routing with NEMO Basic Support, how it may these data packets must go through multiple Home Agents and several
cause a bottleneck to be formed in the home network, and how these levels of encapsulation, which may be avoided. This results in
get amplified with nesting of mobile networks. Closely related to various inefficiencies and problems with packet delivery which can
nesting, we will also look into the sub-optimality even when Mobile ultimately disrupt all communications to and from the Mobile Network
IPv6 Route Optimization is used over NEMO Basic Support. This is Nodes.
followed by a description of security policy in home network that may
forbid transit traffic from Visiting Mobile Nodes in mobile networks. In the following sub-sections, we will describe the effects of a
In addition, we will explore the impact of MRHA tunnel on pinball route with NEMO Basic Support, how it may cause a bottleneck
communications between two Mobile Network Nodes on different links of to be formed in the home network, and how these get amplified with
the same mobile network. We will also provide additional motivations nesting of mobile networks. Closely related to nesting, we will also
for Route Optimization by considering the potential deadlock look into the sub-optimality even when Mobile IPv6 Route Optimization
situation when a Home Agent is part of a mobile network. is used over NEMO Basic Support. This is followed by a description
of security policy in home network that may forbid transit traffic
from Visiting Mobile Nodes in mobile networks. In addition, we will
explore the impact of MRHA tunnel on communications between two
Mobile Network Nodes on different links of the same mobile network.
We will also provide additional motivations for Route Optimization by
considering the potential stalemate situation when a Home Agent is
part of a mobile network.
2.1. Sub-Optimality with NEMO Basic Support 2.1. Sub-Optimality with NEMO Basic Support
With NEMO Basic Support, all packets sent between a Mobile Network With NEMO Basic Support, all packets sent between a Mobile Network
Node and its Correspondent Node are forwarded through the MRHA Node and its Correspondent Node are forwarded through the MRHA
tunnel, resulting in a sub-optimal path between the two nodes. This tunnel, resulting in a pinball route between the two nodes. This has
sub-optimality has the following undesirable effects: the following sub-optimal effects:
o Longer route leading to increased delay and additional o Longer route leading to increased delay and additional
infrastructure load infrastructure load
Because a packet must transit from a mobile network to the Home Because a packet must transit from a mobile network to the Home
Agent then to the Correspondent Node, the transit time of the Agent then to the Correspondent Node, the transit time of the
packet is usually longer than if the packet were to go straight packet is usually longer than if the packet were to go straight
from the mobile network to the Correspondent Node. When the from the mobile network to the Correspondent Node. When the
Correspondent Node (or the mobile network) resides near the Home Correspondent Node (or the mobile network) resides near the Home
Agent, the increase in packet delay can be very small. However Agent, the increase in packet delay can be very small. However
skipping to change at page 6, line 39 skipping to change at page 7, line 39
Agent, may alleviate or even prevent the congestion at the Home Agent Agent, may alleviate or even prevent the congestion at the Home Agent
or Home Link. or Home Link.
2.3. Amplified Sub-Optimality in Nested Mobile Networks 2.3. Amplified Sub-Optimality in Nested Mobile Networks
By allowing other mobile nodes to join a mobile network, and in By allowing other mobile nodes to join a mobile network, and in
particular mobile routers, it is possible to form arbitrary levels of particular mobile routers, it is possible to form arbitrary levels of
nesting of mobile networks. With such nesting, the use of NEMO Basic nesting of mobile networks. With such nesting, the use of NEMO Basic
Support further amplifies the sub-optimality of routing. We call Support further amplifies the sub-optimality of routing. We call
this the amplification effect of nesting, where the undesirable this the amplification effect of nesting, where the undesirable
effects of sub-optimal routing with NEMO Basic Support are amplified effects of a pinball route with NEMO Basic Support are amplified with
with each level of nesting of mobile networks. This is best each level of nesting of mobile networks. This is best illustrated
illustrated by an example shown in Figure 1. by an example shown in Figure 1.
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+ +------+-+ +---+----+ +---+----+ +-+------+
\ | | / \ | | /
+--------+ +------------------------------+ +--------+ +------------------------------+
| MR1_HA |----| Internet |-----CN1 | MR1_HA |----| Internet |-----CN1
+--------+ +------------------------------+ +--------+ +------------------------------+
| |
+---+---+ +---+---+
skipping to change at page 8, line 6 skipping to change at page 9, line 6
---------/ /----------. ---------/ /----------.
-------/ | | /------- -------/ | | /-------
MNN -----( - - | - - - | - - - | - - - | - - (------ CN1 MNN -----( - - | - - - | - - - | - - - | - - (------ CN1
MR3-------\ | | \-------MR3_HA MR3-------\ | | \-------MR3_HA
MR2--------\ \----------MR2_HA MR2--------\ \----------MR2_HA
MR1---------MR1_HA MR1---------MR1_HA
Figure 2: Nesting of Bi-Directional Tunnels Figure 2: Nesting of Bi-Directional Tunnels
This leads to the following problems: This leads to the following problems:
o Sub-optimal routing o Pinball Route
Both inbound and outbound packets will flow via the Home Agents of Both inbound and outbound packets will flow via the Home Agents of
all the Mobile Routers on their paths within the mobile network, all the Mobile Routers on their paths within the mobile network,
with increased latency, less resilience and more bandwidth usage. with increased latency, less resilience and more bandwidth usage.
Appendix B illustrates in detail the packets routes under Appendix B illustrates in detail the packets routes under
different nesting configurations of the Mobile Network Nodes. different nesting configurations of the Mobile Network Nodes.
o Increased Packet Size o Increased Packet Size
An extra IPv6 header is added per level of nesting to all the An extra IPv6 header is added per level of nesting to all the
skipping to change at page 10, line 28 skipping to change at page 11, line 28
particular, there is a mobile home scenario where a (parent) Mobile particular, there is a mobile home scenario where a (parent) Mobile
Router is also a Home Agent for its mobile network. In other words, Router is also a Home Agent for its mobile network. In other words,
the mobile network is itself an aggregation of Mobile Network the mobile network is itself an aggregation of Mobile Network
Prefixes assigned to (children) Mobile Routers. Prefixes assigned to (children) Mobile Routers.
A stalemate situation exists in the case where the parent Mobile A stalemate situation exists in the case where the parent Mobile
Router visits one of its children. The child Mobile Router cannot Router visits one of its children. The child Mobile Router cannot
find its Home Agent in the Internet and thus cannot establish its find its Home Agent in the Internet and thus cannot establish its
MRHA tunnel and forward the visitors traffic. The traffic from the MRHA tunnel and forward the visitors traffic. The traffic from the
parent is thus blocked from reaching the Internet and it will never parent is thus blocked from reaching the Internet and it will never
bind to its own (grand parent) Home Agent. bind to its own (grand parent) Home Agent. Appendix C gives a
detailed illustration of how such a situation can occur.
Then again, a Route Optimization mechanism that bypasses the nested Then again, a Route Optimization mechanism that bypasses the nested
tunnel might enable the parent traffic to reach the Internet and let tunnel might enable the parent traffic to reach the Internet and let
it bind. At that point, the child Mobile Router would be able to it bind. At that point, the child Mobile Router would be able to
reach its parent and bind in turn. Additional nested Route reach its parent and bind in turn. Additional nested Route
Optimization solutions might also enable the child to locate its Home Optimization solutions might also enable the child to locate its Home
Agent in the nested structure and bind regardless of whether the Agent in the nested structure and bind regardless of whether the
Internet is reachable or not. Internet is reachable or not.
3. Conclusion 3. Conclusion
With current NEMO Basic Support, all communications to and from With current NEMO Basic Support, all communications to and from
Mobile Network Nodes must go through the MRHA tunnel when the mobile Mobile Network Nodes must go through the MRHA tunnel when the mobile
network is away. This results in various inefficiencies associated network is away. This results in various inefficiencies associated
with packet delivery. This document investigates such with packet delivery. This document investigates such
inefficiencies, and provides for the motivation behind Route inefficiencies, and provides for the motivation behind Route
Optimization for NEMO. Optimization for NEMO.
We have described the effects of sub-optimal routing with NEMO Basic We have described the sub-optimal effects of pinball routes with NEMO
Support, how it may cause a bottleneck to be formed in the home Basic Support, how they may cause a bottleneck to be formed in the
network, and how they get amplified with nesting of mobile networks. home network, and how they get amplified with nesting of mobile
These effects will also be seen even when Mobile IPv6 Route networks. These effects will also be seen even when Mobile IPv6
Optimization is used over NEMO Basic Support. In addition, other Route Optimization is used over NEMO Basic Support. In addition,
issues concerning the nesting of mobile networks that might provide other issues concerning the nesting of mobile networks that might
additional motivation for a NEMO Route Optimization mechanism were provide additional motivation for a NEMO Route Optimization mechanism
also explored, such as the prohibition of forwarding traffic from a were also explored, such as the prohibition of forwarding traffic
Visiting Mobile Node through a MRHA tunnel due to security concerns, from a Visiting Mobile Node through a MRHA tunnel due to security
the impact of MRHA tunnel on communications between two Mobile concerns, the impact of MRHA tunnel on communications between two
Network Nodes on different links of the same mobile network, and the Mobile Network Nodes on different links of the same mobile network,
possibility of deadlock when Home Agents are nested within a mobile and the possibility of a stalemate situation when Home Agents are
network. nested within a mobile network.
4. IANA Considerations 4. IANA Considerations
This is an informational document and does not require any IANA This is an informational document and does not require any IANA
action. action.
5. Security Considerations 5. Security Considerations
This document highlights some limitations of the NEMO Basic Support. This document highlights some limitations of the NEMO Basic Support.
In particular, some security concerns could prevent interesting In particular, some security concerns could prevent interesting
applications of the protocol, as detailed in Section 2.5. applications of the protocol, as detailed in Section 2.5.
Route Optimization for RFC 3963 [1] might introduce new threats, just Route Optimization for RFC 3963 [1] might introduce new threats, just
as it might alleviate existing ones. This aspect will certainly be a as it might alleviate existing ones. This aspect will certainly be a
key criterion in the evaluation of the proposed solutions. key criterion in the evaluation of the proposed solutions.
6. Acknowledgments 6. Acknowledgments
The authors wish to thank the co-authors of previous drafts from The authors wish to thank the co-authors of previous drafts from
which this draft is derived: Marco Molteni, Paik Eun-Kyoung, Hiroyuki which this draft is derived: Marco Molteni, Paik Eun-Kyoung, Hiroyuki
Ohnishi, Thierry Ernst, Felix Wu, and Souhwan Jung. In addition, Ohnishi, Thierry Ernst, Felix Wu, and Souhwan Jung. Early work by
sincere appreciation is also extended to Jari Arkko, Carlos Masafumi Watari on the extracted appendix was written while still at
Bernardos, Greg Daley, T.J. Kniveton, Henrik Levkowetz, Erik Keio University. In addition, sincere appreciation is also extended
Nordmark, Alexandru Petrescu, Hesham Soliman, Ryuji Wakikawa and to Jari Arkko, Carlos Bernardos, Greg Daley, T.J. Kniveton, Henrik
Patrick Wetterwald for their various contributions. Levkowetz, Erik Nordmark, Alexandru Petrescu, Hesham Soliman, Ryuji
Wakikawa and Patrick Wetterwald for their various contributions.
7. References 7. References
7.1. Normative Reference 7.1. Normative Reference
[1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, [1] 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.
[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-03 (work in progress), draft-ietf-nemo-terminology-04 (work in progress), October 2005.
February 2005.
7.2. Informative Reference 7.2. Informative Reference
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[5] Ernst, T., "Network Mobility Support Goals and Requirements", [5] Ernst, T., "Network Mobility Support Goals and Requirements",
draft-ietf-nemo-requirements-04 (work in progress), draft-ietf-nemo-requirements-05 (work in progress),
February 2005. October 2005.
[6] Deering, S. and B. Zill, "Redundant Address Deletion when [6] Deering, S. and B. Zill, "Redundant Address Deletion when
Encapsulating IPv6 in IPv6", Encapsulating IPv6 in IPv6",
draft-deering-ipv6-encap-addr-deletion-00 (work in progress), draft-deering-ipv6-encap-addr-deletion-00 (work in progress),
November 2001. November 2001.
[7] Petrescu, A., "Threats for Basic Network Mobility Support (NEMO [7] Petrescu, A., Olivereau, A., Janneteau, C., and H-Y. Lach,
threats)", draft-petrescu-nemo-threats-01 (work in progress), "Threats for Basic Network Mobility Support (NEMO threats)",
draft-petrescu-nemo-threats-01 (work in progress),
January 2004. January 2004.
[8] Jung, S., "Threat Analysis on NEMO Basic Operations", [8] Jung, S., Zhao, F., Wu, S., Kim, H-G., and S-W. Sohn, "Threat
Analysis on NEMO Basic Operations",
draft-jung-nemo-threat-analysis-02 (work in progress), draft-jung-nemo-threat-analysis-02 (work in progress),
July 2004. February 2004.
[9] Thubert, P., "NEMO Home Network models", [9] Thubert, P., Wakikawa, R., and V. Devarapalli, "NEMO Home
draft-ietf-nemo-home-network-models-03 (work in progress), Network models", draft-ietf-nemo-home-network-models-05 (work
March 2005. in progress), October 2005.
[10] Draves, R., "Default Address Selection for Internet Protocol [10] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003. version 6 (IPv6)", RFC 3484, February 2003.
Appendix A. Change Log Appendix A. Change Log
o draft-ietf-nemo-ro-problem-statement-02:
* Added Appendix C to illustrate the formation of stalemate
situation in Section 2.7
* Editorial changes to the Abstract to better reflect the
document contents
* Minor editorial changes throughout Section 2
o draft-ietf-nemo-ro-problem-statement-01: o draft-ietf-nemo-ro-problem-statement-01:
* Added text on effect on TCP contributed by Carlos in Sect 2.1 - * Added text on effect on TCP contributed by Carlos in Sect 2.1 -
"Sub-Optimality with NEMO Basic Support" "Sub-Optimality with NEMO Basic Support"
* Added text on VMN using CoA as source address in Appendix B.4.3 * Added text on VMN using CoA as source address in Appendix B.4.3
* Re-written Section 2.5 - "Security Policy Prohibiting Traffic * Re-written Section 2.5 - "Security Policy Prohibiting Traffic
From Visiting Nodes" From Visiting Nodes"
skipping to change at page 15, line 9 skipping to change at page 16, line 9
* Added Section 2.7: Deadlock with a Home Agent Nested in a * Added Section 2.7: Deadlock with a Home Agent Nested in a
Mobile Network Mobile Network
* Appendix B extracted from 'draft-watari-nemo-nested-cn-01.txt' * Appendix B extracted from 'draft-watari-nemo-nested-cn-01.txt'
Appendix B. Various configurations involving Nested Mobile Networks Appendix B. Various configurations involving Nested Mobile Networks
In the following sections, we try to describe different communication In the following sections, we try to describe different communication
models which involve a nested mobile network, and to clarify the models which involve a nested mobile network, and to clarify the
issues for each cases. We illustrate the path followed by packets if issues for each case. We illustrate the path followed by packets if
we assume nodes only use Mobile IPv6 and NEMO Basic Support we assume nodes only use Mobile IPv6 and NEMO Basic Support
mechanisms. Different cases are considered where a Correspondent mechanisms. Different cases are considered where a Correspondent
Node is located in the fixed infrastructure, in a distinct nested Node is located in the fixed infrastructure, in a distinct nested
mobile network as the Mobile Network Node, or in the same nested mobile network as the Mobile Network Node, or in the same nested
mobile network as the Mobile Network Node. Additionally, cases where mobile network as the Mobile Network Node. Additionally, cases where
Correspondent Nodes and Mobile Network Nodes are either standard IPv6 Correspondent Nodes and Mobile Network Nodes are either standard IPv6
nodes or Mobile IPv6 nodes are considered. As defined in [3], nodes or Mobile IPv6 nodes are considered. As defined in [3],
standard IPv6 nodes are nodes with no mobility functions whatsoever, standard IPv6 nodes are nodes with no mobility functions whatsoever,
i.e. they are not Mobile IPv6 nor NEMO enabled. This mean that not i.e. they are not Mobile IPv6 nor NEMO enabled. This mean that not
only can they not move around keeping open connections, but also they only can they not move around keeping open connections, but also they
skipping to change at page 16, line 25 skipping to change at page 17, line 25
LFN IPv6 Node LFN IPv6 Node
The digits represent the number of IPv6 headers. The digits represent the number of IPv6 headers.
Figure 4: MNN and CN are standard IPv6 nodes Figure 4: MNN and CN are standard IPv6 nodes
B.1.2. Case B: VMN and MIPv6 CN B.1.2. Case B: VMN and MIPv6 CN
In this second case, both end nodes are Mobile IPv6 enabled mobile In this second case, both end nodes are Mobile IPv6 enabled mobile
nodes, that is, MNN is a Visiting Mobile Node. Mobile IPv6 route nodes, that is, MNN is a Visiting Mobile Node. Mobile IPv6 route
optimization may thus be initiated between the two and packets optimization may thus be initiated between the two and packets would
wouldn't go through the Home Agent of the Visiting Mobile Node nor not go through the Home Agent of the Visiting Mobile Node nor the
the Home Agent of the Correspondent Node (not shown in the figure). Home Agent of the Correspondent Node (not shown in the figure).
However, packets will still be tunneled between each Mobile Router However, packets will still be tunneled between each Mobile Router
and its respective Home Agent, in both directions. As shown in and its respective Home Agent, in both directions. As shown in
Figure 5, the path between MNN and CN would go through: Figure 5, the path between MNN and CN would go through:
1 2 3 4 3 2 1 1 2 3 4 3 2 1
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN
VMN MIPv6 VMN MIPv6
Figure 5: MNN and CN are MIPv6 mobile nodes Figure 5: MNN and CN are MIPv6 mobile nodes
skipping to change at page 22, line 33 skipping to change at page 23, line 33
+---+---+ +---+---+
| |
-+--+--+- -+--+--+-
MNN CN MNN CN
Figure 15: MNN and CN located behind the same nested MR Figure 15: MNN and CN located behind the same nested MR
B.4.1. Case J: LFN and standard IPv6 CN B.4.1. Case J: LFN and standard IPv6 CN
If both end nodes are Local Fixed Nodes, no special function is If both end nodes are Local Fixed Nodes, no special function is
necessary for optimization of their communication. The path between necessary for optimization of their communications. The path between
the two nodes would go through: the two nodes would go through:
1 1
MNN --- CN MNN --- CN
LFN IPv6 Node LFN IPv6 Node
Figure 16: MNN and CN are standard IPv6 nodes Figure 16: MNN and CN are standard IPv6 nodes
B.4.2. Case K: VMN and MIPv6 CN B.4.2. Case K: VMN and MIPv6 CN
skipping to change at page 23, line 42 skipping to change at page 24, line 42
| 1 | 1
1 2 3 4 3 2 | 1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
IPv6 Node IPv6 Node
Figure 18: MNN is a MIPv6 mobile node and CN is a standard IPv6 node Figure 18: MNN is a MIPv6 mobile node and CN is a standard IPv6 node
However, MNN may also decide to use its care-of address as the source However, MNN may also decide to use its care-of address as the source
address of the packets, thus avoiding the tunneling with the MNN's address of the packets, thus avoiding the tunneling with the MNN's
Home Agent. This is particularly useful for a short-term Home Agent. This is particularly useful for a short-term
communication that may easily be retried if it fails. Default communications that may easily be retried if it fails. Default
Address Selection [10] provides some mechanisms for controlling the Address Selection [10] provides some mechanisms for controlling the
choice of the source address. choice of the source address.
Appendix C. Example of How a Stalemate Situation can Occur
Section 2.7 describes the occurence of a stalemate situation where a
Home Agent of a Mobile Router is nested behind the Mobile Router.
Here, we illustrate a simple example where such a situation can
occur.
Consider a mobility configuration depicted in Figure 19 below. MR1
is served by HA1/BR and MR2 is served by HA2. The 'BR' designation
indicates that HA1 is a border router. Both MR1 and MR2 are at home
in the initial step. HA2 is placed inside the first mobile network,
thus representing a "mobile" Home Agent.
/-----CN
+----------+
home link 1 +--------+ | |
----+-----------------| HA1/BR |---| Internet |
| +--------+ | |
| +----------+
+--+--+ +-----+
| MR1 | | HA2 |
+--+--+ +--+--+
| |
-+--------+-- mobile net 1 / home link 2
|
+--+--+ +--+--+
| MR2 | | LFN |
+--+--+ +--+--+
| |
-+--------+- mobile net 2
Figure 19: Initial Deployment
In Figure 19 above, communications between CN and LFN follows a
direct path as long as both MR1 and MR2 are positioned at home. No
encapsulation intervenes.
In the next step, consider that the MR2's mobile network leaves home
and visits a foreign network, under Access Router (AR) like in
Figure 20 below.
/-----CN
+----------+
home link 1 +--------+ | |
--+-----------| HA1/BR |---| Internet |
| +--------+ | |
+--+--+ +-----+ +----------+
| MR1 | | HA2 | \
+--+--+ +--+--+ +-----+
| | | AR |
-+--------+- mobile net 1 +--+--+
home link 2 |
+--+--+ +-----+
| MR2 | | LFN |
+--+--+ +--+--+
| |
mobile net 2 -+--------+-
Figure 20: Mobile Network 2 Leaves Home
Once MR2 acquires a Care-of Address under AR, the tunnel setup
procedure occurs between MR2 and HA2. MR2 sends Binding Update to
HA2 and HA2 replies Binding Acknowledgement to MR2. The bi-
directional tunnel has MR2 and HA2 as tunnel endpoints. After the
tunnel MR2HA2 has been set up, the path taken by a packet from CN
towards LFN can be summarized as:
CN->BR->MR1->HA2=>MR1=>BR=>AR=>MR2->LFN.
Non-encapsulated packets are marked "->" while encapsulated packets
are marked "=>".
Consider next the attachment of the first mobile network under the
second mobile network, like in Figure 21 below.
After this movement, MR1 acquires a Care-of Address valid in the
second mobile network. Subsequently, it sends a Binding Update
message addressed to HA1. This Binding Update is encapsulated by MR2
and sent towards HA2, which is expected to be placed in mobile net 1
and expected to be at home. Once HA1/BR receives this encapsulated
BU, it tries to deliver to MR1. Since MR1 is not at home, and a
tunnel has not yet been set up between MR1 and HA1, HA1 is not able
to route this packet and drops it. Thus, the tunnel establishment
procedure between MR1 and HA1 is not possible, due to the fact that
the tunnel between MR2 and HA2 has been previously torn down (when
the mobile net 1 has moved from home). The communications between CN
and LFN stops, even though both mobile networks are connected to the
Internet.
/-----CN
+----------+
+--------+ | |
| HA1/BR |---| Internet |
+--------+ | |
+----------+
\
+-----+
| AR |
+--+--+
|
+--+--+ +-----+
| MR2 | | LFN |
+--+--+ +--+--+
| |
mobile net 2 -+--------+-
|
+--+--+ +-----+
| MR1 | | HA2 |
+--+--+ +--+--+
| |
mobile net 1 -+--------+-
Figure 21: Stalemate Situation Occurs
If both tunnels between MR1 and HA1, and between MR2 and HA2 were up
simultaneously, they would have "crossed over" each other. If the
tunnels MR1-HA1 and MR2-HA2 were drawn in Figure 21, it could be
noticed that the path of the tunnel MR1-HA1 includes only one
endpoint of the tunnel MR2-HA2 (the MR2 endpoint). Two MR-HA tunnels
are crossing over each other if the IP path between two endpoints of
one tunnel includes one and only one endpoint of the other tunnel
(assuming that both tunnels are up). When both endpoints of one
tunnel are included in the path of the other tunnel, then tunnels are
simply encapsulating each other.
Authors' Addresses Authors' Addresses
Chan-Wah Ng Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530 Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate Tai Seng Industrial Estate
Singapore 534415 Singapore 534415
SG SG
Phone: +65 65505420 Phone: +65 65505420
 End of changes. 29 change blocks. 
107 lines changed or deleted 259 lines changed or added

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