NEMO Working Group C. Ng
Internet-Draft Panasonic Singapore Labs
Expires: July 1, 2006 P. Thubert
Cisco Systems
M. Watari
KDDI R&D Labs
F. Zhao
UC Davis
December 28, 2005
Network Mobility Route Optimization Problem Statementdraft-ietf-nemo-ro-problem-statement-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 1, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
With current Network Mobility (NEMO) Basic Support, all
communications to and from Mobile Network Nodes must go through the
bi-directional tunnel established between the Mobile Router and Home
Ng, et al. Expires July 1, 2006 [Page 1]

Internet-Draft NEMO RO Problem Statement December 2005
Agent when the mobile network is away. This sub-optimal routing
results in various inefficiencies associated with packet delivery,
such as increased delay and bottleneck links leading to traffic
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.
Ng, et al. Expires July 1, 2006 [Page 2]

Internet-Draft NEMO RO Problem Statement December 20051. Introduction
With current Network Mobility (NEMO) Basic Support [1], all
communications to and from nodes in a mobile network must go through
the bi-directional tunnel established between the Mobile Router and
its Home Agent (also known as the MRHA tunnel) when the mobile
network is away. Although such an arrangement allows Mobile Network
Nodes to reach and be reached by any node on the Internet,
limitations associated to the base protocol degrade overall
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
addressed by the mechanism known as Route Optimization, which is part
of the base protocol. With Mobile IPv6, Route Optimization mostly
improves the end to end path between Mobile Node and Correspondent
Node, with an additional benefit of reducing the load of the Home
Network, thus its name.
NEMO Basic Support presents a number of additional issues, making the
problem more complex, so it was decided to address Route Optimization
separately. In that case, the expected benefits are more dramatic,
and a Route Optimization mechanism could enable connectivity that
would be broken otherwise. In that sense, Route Optimization is even
more important to NEMO Basic Support than it is to Mobile IPv6.
This document explores limitations inherent in NEMO Basic Support,
and their effects on communications between a Mobile Network Node and
its corresponding peer. This is detailed in Section 2. It is
expected for readers to be familiar with general terminologies
related to mobility in [4][2], NEMO related terms defined in [3], and
NEMO goals and requirements [5].
Ng, et al. Expires July 1, 2006 [Page 4]

Internet-Draft NEMO RO Problem Statement December 20052. NEMO Route Optimization Problem Statement
Given the NEMO Basic Support protocol, all data packets to and from
Mobile Network Nodes must go through the Home Agent, even though a
shorter path may exist between the Mobile Network Node and its
Correspondent Node. In addition, with the nesting of Mobile Routers,
these data packets must go through multiple Home Agents and several
levels of encapsulation, which may be avoided. This results in
various inefficiencies and problems with packet delivery which can
ultimately disrupt all communications to and from the Mobile Network
Nodes.
In the following sub-sections, we will describe the effects of a
pinball route with NEMO Basic Support, how it may cause a bottleneck
to be formed in the home network, and how these get amplified with
nesting of mobile networks. Closely related to nesting, we will also
look into the sub-optimality even when Mobile IPv6 Route Optimization
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
With NEMO Basic Support, all packets sent between a Mobile Network
Node and its Correspondent Node are forwarded through the MRHA
tunnel, resulting in a pinball route between the two nodes. This has
the following sub-optimal effects:
o Longer route leading to increased delay and additional
infrastructure load
Because a packet must transit from a mobile network to the Home
Agent then to the Correspondent Node, the transit time of the
packet is usually longer than if the packet were to go straight
from the mobile network to the Correspondent Node. When the
Correspondent Node (or the mobile network) resides near the Home
Agent, the increase in packet delay can be very small. However
when the mobile network and the Correspondent Node are relatively
near to one another but far away from the Home Agent on the
Internet, the increase in delay is very large. Applications such
as real-time multimedia streaming may not be able to tolerate such
increase in packet delay. In general, the increase in delay may
Ng, et al. Expires July 1, 2006 [Page 5]

Internet-Draft NEMO RO Problem Statement December 2005
also impact the performance of transport protocols such as TCP,
since the sending rate of TCP is partly determined by the round-
trip-time (RTT) perceived by the communication peers.
Moreover, by using a longer route, the total resource utilization
for the traffic would be much higher than if the packets were to
follow a direct path between the Mobile Network Node and
Correspondent Node. This would result in additional load in the
infrastructure.
o Increased packet overhead
The encapsulation of packets in the MRHA tunnel results in
increased packet size due to addition of an outer header. This
reduces the bandwidth efficiency, as IPv6 header can be quite
substantial relative to the payload for applications such as voice
samples. For instance, given a voice application using a 8kbps
algorithm (e.g. G.729) and taking a voice sample every 20ms (as
in RFC 1889), the packet transmission rate will be 50 packets per
second. Each additional IPv6 header is an extra 320 bits per
packet (i.e. 16kbps), which is twice the actual payload!
o Increased processing delay
The encapsulation of packets in the MRHA tunnel also results in
increased processing delay at the points of encapsulation and
decapsulation. Such increased processing may include encryption/
decryption, topological correctness verifications, MTU
computation, fragmentation and reassembly.
o Increased chances of packet fragmentation
The augmentation in packet size due to packet encapsulation may
increase the chances of the packet being fragmented along the MRHA
tunnel. This can occur if there is no prior path MTU discovery
conducted, or if the MTU discovery mechanism did not take into
account the encapsulation of packets. Packets fragmentation will
result in a further increase in packet delays, and further
reduction of bandwidth efficiency.
o Increased susceptibility to link failure
Under the assumption that each link has the same probability of
link failure, a longer routing path would be more susceptibility
to link failure. Thus, packets routed through the MRHA tunnel may
be subjected to a higher probability of being lost or delayed due
to link failure, compared to packets that traverse directly
between the Mobile Network Node and its Correspondent Node.
Ng, et al. Expires July 1, 2006 [Page 6]

Internet-Draft NEMO RO Problem Statement December 20052.2. Bottleneck in Home Network
Apart from the increase in packet delay and infrastructure load,
forwarding packets through the Home Agent may also lead to either the
Home Agent or the Home Link becoming a bottleneck for the aggregated
traffic from/to all the Mobile Network Nodes. A congestion at home
would lead to additional packet delay, or even packet loss. In
addition, Home Agent operations such as security check, packet
interception and tunneling might not be as optimized in the Home
Agent software as plain packet forwarding. This could further limit
the Home Agent capacity for data traffic. Furthermore, with all
traffic having to pass through the Home Link, the Home Link becomes a
single point of failure for the mobile network.
Data packets that are delayed or discarded due to congestion at the
home network would cause additional performance degradation to
applications. Signaling packets, such as Binding Update messages,
that are delayed or discarded due to congestion at the home network,
may affect the establishment or update of bi-directional tunnels,
causing disruption of all traffic flow through these tunnels.
A NEMO Route Optimization mechanism that allows the Mobile Network
Nodes to communicate with their Correspondent Nodes via a path that
is different from the MRHA tunneling and thereby avoiding the Home
Agent, may alleviate or even prevent the congestion at the Home Agent
or Home Link.
2.3. Amplified Sub-Optimality in Nested Mobile Networks
By allowing other mobile nodes to join a mobile network, and in
particular mobile routers, it is possible to form arbitrary levels of
nesting of mobile networks. With such nesting, the use of NEMO Basic
Support further amplifies the sub-optimality of routing. We call
this the amplification effect of nesting, where the undesirable
effects of a pinball route with NEMO Basic Support are amplified with
each level of nesting of mobile networks. This is best illustrated
by an example shown in Figure 1.
Ng, et al. Expires July 1, 2006 [Page 7]

Internet-Draft NEMO RO Problem Statement December 2005
This leads to the following problems:
o Pinball Route
Both inbound and outbound packets will flow via the Home Agents of
all the Mobile Routers on their paths within the mobile network,
with increased latency, less resilience and more bandwidth usage.
Appendix B illustrates in detail the packets routes under
different nesting configurations of the Mobile Network Nodes.
o Increased Packet Size
An extra IPv6 header is added per level of nesting to all the
packets. The header compression suggested in [6] cannot be
applied because both the source and destination (the intermediate
Mobile Router and its Home Agent), are different hop to hop.
Nesting also amplifies the probability of congestion at the home
networks of the upstream Mobile Routers. In addition, the Home Link
of each upstream Mobile Router will also be a single point of failure
for the nested Mobile Router.
2.4. Sub-Optimality with Combined Mobile IPv6 Route Optimization
When a Mobile IPv6 host joins a mobile network, it becomes a Visiting
Mobile Node of the mobile network. Packets sent to and from the
Visiting Mobile Node will have to be routed not only via the Home
Agent of the Visiting Mobile Node, but also via the Home Agent of the
Mobile Router in the mobile network. This suffers the same
amplification effect of nested mobile network mentioned in
Section 2.3.
In addition, although Mobile IPv6 [4] allows a mobile host to perform
Route Optimization with its Correspondent Node in order to avoid
tunneling with its Home Agent, the "optimized" route is no longer
optimized when the mobile host is attached to a mobile network. This
is because the route between the mobile host and its Correspondent
Node is subjected to the sub-optimality introduced by the MRHA
tunnel. Interested readers may refer to Appendix B for examples of
how the routes will appear with nesting of Mobile IPv6 hosts in
mobile networks.
The readers should also note that the same sub-optimality would apply
when the mobile host is outside the mobile network and its
Correspondent Node is in the mobile network.
Ng, et al. Expires July 1, 2006 [Page 9]

Internet-Draft NEMO RO Problem Statement December 20052.5. Security Policy Prohibiting Traffic From Visiting Nodes
NEMO Basic Support requires all traffic from visitors to be tunneled
to the Mobile Router's Home Agent. This might represent a breach in
the security of the home network (some specific attacks against the
Mobile Router's binding by rogue visitors have been documented in
[7][8]). Administrators might thus fear that malicious packets will
be routed into the Home Network via the bi-directional tunnel. As a
consequence, it can be expected that in many deployment scenarios,
policies will be put in place to prevent unauthorized Visiting Mobile
Nodes from attaching to the Mobile Router.
However, there are deployment scenarios where allowing unauthorized
Visiting Mobile Nodes is actually desirable. For instance, when
Mobile Routers attach to other Mobile Routers and form a nested NEMO,
they depend on each other to reach the Internet. When Mobile Routers
have no prior knowledge of one another (no security association, AAA,
PKI etc...), it could still be acceptable to forward packets,
provided that the packets are not tunneled back to the Home Networks.
A Route Optimization mechanism that allows traffic from Mobile
Network Nodes to by-pass the bi-directional tunnel between a Mobile
Router and its Home Agent would be a necessary first step towards a
Tit for Tat model, where MRs would benefit from a reciprocal
altruism, based on anonymity and innocuousness, to extend the
Internet infrastructure dynamically.
2.6. Instability of Communications within a Nested Mobile Network
Within a nested mobile network, two Mobile Network Nodes may
communicate with each other. Let us consider the previous example
illustrated in Figure 1 where MNN and CN2 are sharing a communication
session. With NEMO Basic Support, a packet sent from MNN to CN2 will
need to be forwarded to the Home Agent of each Mobile Router before
reaching CN2. Whereas, a packet following the direct path between
them need not even leave the mobile network. Readers are referred to
Appendix B.3 for detailed illustration of the resulting routing
paths.
Apart from the consequences of increased packet delay and packet size
which are discussed in previous sub-sections, there are two
additional effects that are undesirable:
o when the nested mobile network is disconnected from the Internet
(e.g. MR1 loses its egress connectivity), MNN and CN2 can no
longer communicate with each other, even though the direct path
from MNN to CN2 is unaffected;
Ng, et al. Expires July 1, 2006 [Page 10]

Internet-Draft NEMO RO Problem Statement December 2005
o the egress link(s) of the root Mobile Router (i.e. MR1) becomes a
bottleneck for all the traffic that is coming in and out of the
nested mobile network.
A Route Optimization mechanism could allow traffic between two Mobile
Network Nodes nested within the same mobile network to follow a
direct path between them, without being routed out of the mobile
network. This may also off-load the processing burden of the
upstream Mobile Routers when the direct path between the two Mobile
Network Nodes does not traverse these Mobile Routers.
2.7. Stalemate with a Home Agent Nested in a Mobile Network
Several configurations for the Home Network are described in [9]. In
particular, there is a mobile home scenario where a (parent) Mobile
Router is also a Home Agent for its mobile network. In other words,
the mobile network is itself an aggregation of Mobile Network
Prefixes assigned to (children) Mobile Routers.
A stalemate situation exists in the case where the parent Mobile
Router visits one of its children. The child Mobile Router cannot
find its Home Agent in the Internet and thus cannot establish its
MRHA tunnel and forward the visitors traffic. The traffic from the
parent is thus blocked from reaching the Internet and it will never
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
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
reach its parent and bind in turn. Additional nested Route
Optimization solutions might also enable the child to locate its Home
Agent in the nested structure and bind regardless of whether the
Internet is reachable or not.
Ng, et al. Expires July 1, 2006 [Page 11]

Internet-Draft NEMO RO Problem Statement December 20053. Conclusion
With current NEMO Basic Support, all communications to and from
Mobile Network Nodes must go through the MRHA tunnel when the mobile
network is away. This results in various inefficiencies associated
with packet delivery. This document investigates such
inefficiencies, and provides for the motivation behind Route
Optimization for NEMO.
We have described the sub-optimal effects of pinball routes with NEMO
Basic Support, how they may cause a bottleneck to be formed in the
home network, and how they get amplified with nesting of mobile
networks. These effects will also be seen even when Mobile IPv6
Route Optimization is used over NEMO Basic Support. In addition,
other issues concerning the nesting of mobile networks that might
provide additional motivation for a NEMO Route Optimization mechanism
were also explored, such as the prohibition of forwarding traffic
from a Visiting Mobile Node through a MRHA tunnel due to security
concerns, the impact of MRHA tunnel on communications between two
Mobile Network Nodes on different links of the same mobile network,
and the possibility of a stalemate situation when Home Agents are
nested within a mobile network.
4. IANA Considerations
This is an informational document and does not require any IANA
action.
5. Security Considerations
This document highlights some limitations of the NEMO Basic Support.
In particular, some security concerns could prevent interesting
applications of the protocol, as detailed in Section 2.5.
Route Optimization for RFC 3963 [1] might introduce new threats, just
as it might alleviate existing ones. This aspect will certainly be a
key criterion in the evaluation of the proposed solutions.
Ng, et al. Expires July 1, 2006 [Page 12]

Internet-Draft NEMO RO Problem Statement December 20056. Acknowledgments
The authors wish to thank the co-authors of previous drafts from
which this draft is derived: Marco Molteni, Paik Eun-Kyoung, Hiroyuki
Ohnishi, Thierry Ernst, Felix Wu, and Souhwan Jung. Early work by
Masafumi Watari on the extracted appendix was written while still at
Keio University. In addition, sincere appreciation is also extended
to Jari Arkko, Carlos Bernardos, Greg Daley, T.J. Kniveton, Henrik
Levkowetz, Erik Nordmark, Alexandru Petrescu, Hesham Soliman, Ryuji
Wakikawa and Patrick Wetterwald for their various contributions.
Ng, et al. Expires July 1, 2006 [Page 13]

Internet-Draft NEMO RO Problem Statement December 2005Appendix B. Various configurations involving Nested Mobile Networks
In the following sections, we try to describe different communication
models which involve a nested mobile network, and to clarify the
issues for each case. We illustrate the path followed by packets if
we assume nodes only use Mobile IPv6 and NEMO Basic Support
mechanisms. Different cases are considered where a Correspondent
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. Additionally, cases where
Correspondent Nodes and Mobile Network Nodes are either standard IPv6
nodes or Mobile IPv6 nodes are considered. As defined in [3],
standard IPv6 nodes are nodes with no mobility functions whatsoever,
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
cannot process Binding Updates sent by peers.
B.1. CN located in the fixed infrastructure
The most typical configuration is the case where a Mobile Network
Node communicates with a Correspondent Node attached in the fixed
infrastructure. Figure 3 below shows an example of such topology.
+--------+ +--------+ +--------+
| MR1_HA | | MR2_HA | | MR3_HA |
+---+----+ +---+----+ +---+----+
| | |
+-------------------------+
| Internet |----+ CN
+-------------------------+
| |
+---+---+ +--+-----+
root-MR | MR1 | | VMN_HA |
+---+---+ +--------+
|
+---+---+
sub-MR | MR2 |
+---+---+
|
+---+---+
sub-MR | MR3 |
+---+---+
|
----+----
MNN
Figure 3: CN located at the infrastructure
Ng, et al. Expires July 1, 2006 [Page 16]

Internet-Draft NEMO RO Problem Statement December 2005B.1.1. Case A: LFN and standard IPv6 CN
The simplest case is where both MNN and CN are fixed nodes with no
mobility functions. That is, MNN is a Local Fixed Node, and CN is a
standard IPv6 node. Packets are encapsulated between each Mobile
Router and its respective Home Agent. As shown in Figure 4, in such
case, the path between the two nodes would go through:
1 2 3 4 3 2 1
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN
LFN IPv6 Node
The digits represent the number of IPv6 headers.
Figure 4: MNN and CN are standard IPv6 nodes
B.1.2. Case B: VMN and MIPv6 CN
In this second case, both end nodes are Mobile IPv6 enabled mobile
nodes, that is, MNN is a Visiting Mobile Node. Mobile IPv6 route
optimization may thus be initiated between the two and packets would
not go through the Home Agent of the Visiting Mobile Node nor the
Home Agent of the Correspondent Node (not shown in the figure).
However, packets will still be tunneled between each Mobile Router
and its respective Home Agent, in both directions. As shown in
Figure 5, the path between MNN and CN would go through:
1 2 3 4 3 2 1
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN
VMN MIPv6
Figure 5: MNN and CN are MIPv6 mobile nodes
B.1.3. Case C: VMN and standard IPv6 CN
When the communication involves a Mobile IPv6 node either as a
Visiting Mobile Node or as a Correspondent Node, Mobile IPv6 route
optimization cannot be performed because the standard IPv6
Correspondent Node cannot process Mobile IPv6 signaling. Therefore,
MNN would establish a bi-directional tunnel with its HA, which causes
the flow to go out the nested NEMO. Packets between MNN and CN would
thus go through MNN's own Home Agent (VMN_HA). The path would
therefore be as shown on Figure 6:
Ng, et al. Expires July 1, 2006 [Page 17]

Internet-Draft NEMO RO Problem Statement December 2005
1
MNN --- CN
VMN MIPv6 Node
Figure 17: MNN and CN are MIPv6 mobile nodes
If the root Mobile Router is disconnected while the nodes exchange
keys for the Return Routability procedure, they may not communicate
even though they are connected on the same link.
B.4.3. Case L: VMN and standard IPv6 CN
When the communication involves a Mobile IPv6 node either as a
Visiting Mobile Network Node or as a Correspondent Node, Mobile IPv6
Route Optimization cannot be performed. Therefore, even though the
two nodes are on the same link, MNN will establish a bi-directional
tunnel with it's Home Agent, which causes the flow to go out the
nested mobile network. Path between MNN and CN would require another
Home Agent (VMN_HA) to go through for this Mobile IPv6 node:
2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 2
|
VMN_HA
|
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
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
address of the packets, thus avoiding the tunneling with the MNN's
Home Agent. This is particularly useful for a short-term
communications that may easily be retried if it fails. Default
Address Selection [10] provides some mechanisms for controlling the
choice of the source address.
Ng, et al. Expires July 1, 2006 [Page 24]

Internet-Draft NEMO RO Problem Statement December 2005Appendix C. Example of How a Stalemate Situation can OccurSection 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.
Ng, et al. Expires July 1, 2006 [Page 25]

Internet-Draft NEMO RO Problem Statement December 2005
/-----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.
Ng, et al. Expires July 1, 2006 [Page 26]

Internet-Draft NEMO RO Problem Statement December 2005
/-----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.
Ng, et al. Expires July 1, 2006 [Page 27]

Internet-Draft NEMO RO Problem Statement December 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ng, et al. Expires July 1, 2006 [Page 29]