draft-ietf-nemo-ro-problem-statement-00.txt   draft-ietf-nemo-ro-problem-statement-01.txt 
NEMO Working Group C. Ng NEMO Working Group C. Ng
Internet-Draft Panasonic Singapore Labs Internet-Draft Panasonic Singapore Labs
Expires: January 5, 2006 P. Thubert Expires: April 14, 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
July 4, 2005 October 11, 2005
Network Mobility Route Optimization Problem Statement Network Mobility Route Optimization Problem Statement
draft-ietf-nemo-ro-problem-statement-00 draft-ietf-nemo-ro-problem-statement-01
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 January 5, 2006. This Internet-Draft will expire on April 14, 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 results in various
inefficiencies associated with packet delivery. This document inefficiencies associated with packet delivery. This document
investigates such inefficiencies, and provides for the motivation investigates such inefficiencies, and provides for the motivation
behind Route Optimization (RO) for NEMO. behind Route Optimization (RO) for NEMO.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. NEMO Route Optimization Problem Statement . . . . . . . . . . 4 2. NEMO Route Optimization Problem Statement . . . . . . . . . . 4
2.1 Sub-Optimality with NEMO Basic Support . . . . . . . . . . 4 2.1. Sub-Optimality with NEMO Basic Support . . . . . . . . . . 4
2.2 Bottleneck in Home Network . . . . . . . . . . . . . . . . 6 2.2. Bottleneck in Home Network . . . . . . . . . . . . . . . . 6
2.3 Amplified Sub-Optimality in Nested Mobile Networks . . . . 6 2.3. Amplified Sub-Optimality in Nested Mobile Networks . . . . 6
2.4 Sub-Optimality with Combined Mobile IPv6 Route 2.4. Sub-Optimality with Combined Mobile IPv6 Route
Optimization . . . . . . . . . . . . . . . . . . . . . . . 8 Optimization . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Security Policy Prohibiting Traffic From Visiting Nodes . 8 2.5. Security Policy Prohibiting Traffic From Visiting Nodes . 9
2.6 Instability of Communications within a Nested Mobile 2.6. Instability of Communications within a Nested Mobile
Network . . . . . . . . . . . . . . . . . . . . . . . . . 9 Network . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.7 Deadlock with a Home Agent Nested in a Mobile Network . . 10 2.7. Stalemate with a Home Agent Nested in a Mobile Network . . 10
3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1 Normative Reference . . . . . . . . . . . . . . . . . . . 12 7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 13
7.2 Informative Reference . . . . . . . . . . . . . . . . . . 12 7.2. Informative Reference . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 14
A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix B. Various configurations involving Nested Mobile
B. Various configurations involving Nested Mobile Networks . . . 15 Networks . . . . . . . . . . . . . . . . . . . . . . 15
B.1 CN located in the fixed infrastructure . . . . . . . . . . 15 B.1. CN located in the fixed infrastructure . . . . . . . . . . 15
B.1.1 Case A: LFN and standard IPv6 CN . . . . . . . . . . . 16 B.1.1. Case A: LFN and standard IPv6 CN . . . . . . . . . . . 16
B.1.2 Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . 16 B.1.2. Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . 16
B.1.3 Case C: VMN and standard IPv6 CN . . . . . . . . . . . 16 B.1.3. Case C: VMN and standard IPv6 CN . . . . . . . . . . . 16
B.2 CN located in distinct nested NEMOs . . . . . . . . . . . 17 B.2. CN located in distinct nested NEMOs . . . . . . . . . . . 17
B.2.1 Case D: LFN and standard IPv6 CN . . . . . . . . . . . 18 B.2.1. Case D: LFN and standard IPv6 CN . . . . . . . . . . . 18
B.2.2 Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . 18 B.2.2. Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . 18
B.2.3 Case F: VMN and standard IPv6 CN . . . . . . . . . . . 18 B.2.3. Case F: VMN and standard IPv6 CN . . . . . . . . . . . 18
B.3 CN and MNN located in the same nested NEMO . . . . . . . . 19 B.3. CN and MNN located in the same nested NEMO . . . . . . . . 19
B.3.1 Case G: LFN and standard IPv6 CN . . . . . . . . . . . 20 B.3.1. Case G: LFN and standard IPv6 CN . . . . . . . . . . . 20
B.3.2 Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . 21 B.3.2. Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . 20
B.3.3 Case I: VMN and standard IPv6 CN . . . . . . . . . . . 21 B.3.3. Case I: VMN and standard IPv6 CN . . . . . . . . . . . 21
B.4 CN located behind the same nested MR . . . . . . . . . . . 22 B.4. CN located behind the same nested MR . . . . . . . . . . . 21
B.4.1 Case J: LFN and standard IPv6 CN . . . . . . . . . . . 22 B.4.1. Case J: LFN and standard IPv6 CN . . . . . . . . . . . 22
B.4.2 Case K: VMN and MIPv6 CN . . . . . . . . . . . . . . . 23 B.4.2. Case K: VMN and MIPv6 CN . . . . . . . . . . . . . . . 22
B.4.3 Case L: VMN and standard IPv6 CN . . . . . . . . . . . 23 B.4.3. Case L: VMN and standard IPv6 CN . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25
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 when the mobile network is away. Although such an
arrangement allows Mobile Network Nodes to reach and be reached by arrangement allows Mobile Network Nodes to reach and be reached by
any node on the Internet at all time, limitations associated to the any node on the Internet , limitations associated to the base
base protocol degrade overall performance of the network, and, protocol degrade overall performance of the network, and, ultimately,
ultimately, can prevent all communications to and from the Mobile can prevent all communications to and from the Mobile Network Nodes.
Network Nodes.
Some of these concerns already exist with Mobile IPv6 [2] 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
separately. In that case, the expected benefits are more dramatic, separately. In that case, the expected benefits are more dramatic,
and a Route Optimization mechanism could enable connectivity that and a Route Optimization mechanism could enable connectivity that
would be broken otherwise. In that sense, Route Optimization is even would be broken otherwise. In that sense, Route Optimization is even
more important to NEMO Basic Support than it is to Mobile IPv6. more important to NEMO Basic Support than it is to Mobile IPv6.
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 [2][3], NEMO related terms defined in [4], 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 In essence, the goal of Route Optimization in NEMO is to reduce
limitations and sub-optimalities introduced by the bi-directional limitations and sub-optimalities introduced by the bi-directional
tunnel between a Mobile Router and its Home Agent (also known as the tunnel between a Mobile Router and its Home Agent (also known as the
MRHA tunnel). In the following sub-sections, we will describe the MRHA tunnel). In the following sub-sections, we will describe the
effects of sub-optimal routing with NEMO Basic Support, how it may effects of sub-optimal routing with NEMO Basic Support, how it may
cause a bottleneck to be formed in the home network, and how these cause a bottleneck to be formed in the home network, and how these
skipping to change at page 4, line 24 skipping to change at page 4, line 24
nesting, we will also look into the sub-optimality even when Mobile nesting, we will also look into the sub-optimality even when Mobile
IPv6 Route Optimization is used over NEMO Basic Support. This is IPv6 Route Optimization is used over NEMO Basic Support. This is
followed by a description of security policy in home network that may followed by a description of security policy in home network that may
forbid transit traffic from Visiting Mobile Nodes in mobile networks. forbid transit traffic from Visiting Mobile Nodes in mobile networks.
In addition, we will explore the impact of MRHA tunnel on In addition, we will explore the impact of MRHA tunnel on
communications between two Mobile Network Nodes on different links of communications between two Mobile Network Nodes on different links of
the same mobile network. We will also provide additional motivations the same mobile network. We will also provide additional motivations
for Route Optimization by considering the potential deadlock for Route Optimization by considering the potential deadlock
situation when a Home Agent is part of a mobile network. 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 sub-optimal path between the two nodes. This
sub-optimality has the following undesirable effects: sub-optimality has the following undesirable 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 higher 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. In the best from the mobile network to the Correspondent Node. When the
case, where the Correspondent Node (or the mobile network) resides Correspondent Node (or the mobile network) resides near the Home
near the Home Agent, the increase in packet delay is minimal. In Agent, the increase in packet delay can be very small. However
the worst case, where the mobile network and the Correspondent when the mobile network and the Correspondent Node are relatively
Node are relatively near to one another but far away from the Home near to one another but far away from the Home Agent on the
Agent on the Internet, the increase in delay is tremendous. Internet, the increase in delay is very large. Applications such
Applications such as real-time multimedia streaming may not be as real-time multimedia streaming may not be able to tolerate such
able to tolerate such increase in packet delay. increase in packet delay. In general, the increase in delay may
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 Moreover, by using a longer route, the total resource utilization
for the traffic would be much higher than if the packets were to for the traffic would be much higher than if the packets were to
follow a direct path between the Mobile Network Node and follow a direct path between the Mobile Network Node and
Correspondent Node. This would result in additional load in the Correspondent Node. This would result in additional load in the
infrastructure. infrastructure.
o Increased packets overhead o Increased packet overhead
The encapsulation of packets in the MRHA tunnel results in The encapsulation of packets in the MRHA tunnel results in
increased packet size due to addition of an outer header. This increased packet size due to addition of an outer header. This
reduces the bandwidth efficiency, as IPv6 header can be quite reduces the bandwidth efficiency, as IPv6 header can be quite
substantial relative to the payload for applications such as voice substantial relative to the payload for applications such as voice
samples. For instance, consider a voice application using a 8kbps samples. For instance, given a voice application using a 8kbps
algorithm (e.g. G.729) and taking a voice sample every 20ms (as 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 in RFC 1889), the packet transmission rate will be 50 packets per
second. IPv6/UDP/RTP header cause an overhead of 384 bits (i.e. second. Each additional IPv6 header is an extra 320 bits per
19200bps of overhead). Each additional IPv6 header is an extra packet (i.e. 16kbps), which is twice the actual payload!
16kpbs, which is twice the actual payload.
o Increased processing delay o Increased processing delay
The encapsulation of packets in the MRHA tunnel also results in The encapsulation of packets in the MRHA tunnel also results in
increased processing delay at the points of encapsulation and increased processing delay at the points of encapsulation and
decapsulation. Such increased processing may include encryption/ decapsulation. Such increased processing may include encryption/
decryption, topological correctness verifications, MTU decryption, topological correctness verifications, MTU
computation, fragmentation and reassembly. computation, fragmentation and reassembly.
o Increased chances of packet fragmentation o Increased chances of packet fragmentation
skipping to change at page 6, line 5 skipping to change at page 6, line 5
o Increased susceptibility to link failure o Increased susceptibility to link failure
Under the assumption that each link has the same probability of Under the assumption that each link has the same probability of
link failure, a longer routing path would be more susceptibility link failure, a longer routing path would be more susceptibility
to link failure. Thus, packets routed through the MRHA tunnel may to link failure. Thus, packets routed through the MRHA tunnel may
be subjected to a higher probability of being lost or delayed due be subjected to a higher probability of being lost or delayed due
to link failure, compared to packets that traverse directly to link failure, compared to packets that traverse directly
between the Mobile Network Node and its Correspondent Node. between the Mobile Network Node and its Correspondent Node.
2.2 Bottleneck in Home Network 2.2. Bottleneck in Home Network
Apart from the increase in packet delay and infrastructure load, Apart from the increase in packet delay and infrastructure load,
forwarding packets through the Home Agent may also lead to either the forwarding packets through the Home Agent may also lead to either the
Home Agent or the Home Link becoming a bottleneck for the aggregated Home Agent or the Home Link becoming a bottleneck for the aggregated
traffic from/to all the Mobile Network Nodes. A congestion at home traffic from/to all the Mobile Network Nodes. A congestion at home
would lead to additional packet delay, or even packet loss. In would lead to additional packet delay, or even packet loss. In
addition, Home Agent operations such as security check, packet addition, Home Agent operations such as security check, packet
interception and tunneling might not be as optimized in the Home interception and tunneling might not be as optimized in the Home
Agent software as plain packet forwarding. This could further limit Agent software as plain packet forwarding. This could further limit
the Home Agent capacity for data traffic. Furthermore, with all the Home Agent capacity for data traffic. Furthermore, with all
skipping to change at page 6, line 32 skipping to change at page 6, line 32
that are delayed or discarded due to congestion at the home network, that are delayed or discarded due to congestion at the home network,
may affect the establishment or update of bi-directional tunnels, may affect the establishment or update of bi-directional tunnels,
causing disruption of all traffic flow through these tunnels. causing disruption of all traffic flow through these tunnels.
A NEMO Route Optimization mechanism that allows the Mobile Network A NEMO Route Optimization mechanism that allows the Mobile Network
Nodes to communicate with their Correspondent Nodes via a path that Nodes to communicate with their Correspondent Nodes via a path that
is different from the MRHA tunneling and thereby avoiding the Home is different from the MRHA tunneling and thereby avoiding the Home
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 sub-optimal routing with NEMO Basic Support are amplified
with each level of nesting of mobile networks. This is best with each level of nesting of mobile networks. This is best
illustrated by an example shown in Figure 1. illustrated by an example shown in Figure 1.
skipping to change at page 8, line 8 skipping to change at page 8, line 17
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
packets. The header compression suggested in [7] cannot be packets. The header compression suggested in [6] cannot be
applied because both the source and destination (the intermediate applied because both the source and destination (the intermediate
Mobile Router and its Home Agent), are different hop to hop. Mobile Router and its Home Agent), are different hop to hop.
Nesting also amplifies the probability of congestion at the home Nesting also amplifies the probability of congestion at the home
networks of the upstream Mobile Routers. In addition, the Home Link networks of the upstream Mobile Routers. In addition, the Home Link
of each upstream Mobile Router will also be a single point of failure of each upstream Mobile Router will also be a single point of failure
for the nested Mobile Router. for the nested Mobile Router.
2.4 Sub-Optimality with Combined Mobile IPv6 Route Optimization 2.4. Sub-Optimality with Combined Mobile IPv6 Route Optimization
When a Mobile IPv6 host joins a mobile network, it becomes a Visiting 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 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 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 Agent of the Visiting Mobile Node, but also via the Home Agent of the
Mobile Router in the mobile network. This suffers the same Mobile Router in the mobile network. This suffers the same
amplification effect of nested mobile network mentioned in amplification effect of nested mobile network mentioned in
Section 2.3. Section 2.3.
In addition, although Mobile IPv6 [2] allows a mobile host to perform In addition, although Mobile IPv6 [4] allows a mobile host to perform
Route Optimization with its Correspondent Node in order to avoid Route Optimization with its Correspondent Node in order to avoid
tunneling with its Home Agent, the "optimized" route is no longer tunneling with its Home Agent, the "optimized" route is no longer
optimized when the mobile host is attached to a mobile network. This optimized when the mobile host is attached to a mobile network. This
is because the route between the mobile host and its Correspondent is because the route between the mobile host and its Correspondent
Node is subjected to the sub-optimality introduced by the MRHA Node is subjected to the sub-optimality introduced by the MRHA
tunnel. Interested readers may refer to Appendix B for examples of tunnel. Interested readers may refer to Appendix B for examples of
how the routes will appear with nesting of Mobile IPv6 hosts in how the routes will appear with nesting of Mobile IPv6 hosts in
mobile networks. mobile networks.
The readers should also note that the same sub-optimality would apply The readers should also note that the same sub-optimality would apply
when the mobile host is outside the mobile network and its when the mobile host is outside the mobile network and its
Correspondent Node is in the mobile network. Correspondent Node is in the mobile network.
2.5 Security Policy Prohibiting Traffic From Visiting Nodes 2.5. Security Policy Prohibiting Traffic From Visiting Nodes
The ability of Mobile Routers to attach to other Mobile Routers NEMO Basic Support requires all traffic from visitors to be tunneled
allows the possibility for them to form a mesh that extends the to the Mobile Router's Home Agent. This might represent a breach in
infrastructure dynamically, relaying each others packets to the the security of the home network (some specific attacks against the
Internet. By providing reachability to one another, they cooperate Mobile Router's binding by rogue visitors have been documented in
to improve the network availability for all parties. When Mobile [7][8]). Administrators might thus fear that malicious packets will
Routers have no prior knowledge of their peers (no Security be routed into the Home Network via the bi-directional tunnel. As a
association, AAA, PKI etc...) it can still be mutually beneficial to consequence, it can be expected that in many deployment scenarios,
apply a form of reciprocal altruism based on anonymity and policies will be put in place to prevent unauthorized Visiting Mobile
innocuousness. In particular, it is possible to adopt a tit for tat Nodes from attaching to the Mobile Router.
(T4T) strategy and forward traffic unless the other party proves to
be uncooperative when it is solicited.
On the other hand, NEMO Basic Support requires all the traffic from a However, there are deployment scenarios where allowing unauthorized
visitor to be tunneled to the Mobile Router's Home Agent. This might Visiting Mobile Nodes is actually desirable. For instance, when
represent a breach in the security of the home network (some specific Mobile Routers attach to other Mobile Routers and form a nested NEMO,
attacks against the Mobile Router binding by rogue visitors have been they depend on each other to reach the Internet. When Mobile Routers
documented in [8][9]). As a consequence, it can be expected that in have no prior knowledge of one another (no security association, AAA,
many deployments, policies will be put in place to prevent untrusted PKI etc...), it could still be acceptable to forward packets,
visitors from attaching to the Mobile Router. This will block T4T provided that the packets are not tunneled back to the Home Networks.
nested NEMO for developing widely.
A Route Optimization mechanism that would prevent the multiple re- A Route Optimization mechanism that allows traffic from Mobile
encapsulation of the packets by nested Mobile Routers might as a side Network Nodes to by-pass the bi-directional tunnel between a Mobile
effect alleviate this limitation and leave the way to a more open and Router and its Home Agent would be a necessary first step towards a
efficient model for the fringe of the Internet. 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 2.6. Instability of Communications within a Nested Mobile Network
Within a nested mobile network, two Mobile Network Nodes may Within a nested mobile network, two Mobile Network Nodes may
communicate with each other. Let us consider the previous example communicate with each other. Let us consider the previous example
illustrated in Figure 1 where MNN and CN2 are sharing a communication 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 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 need to be forwarded to the Home Agent of each Mobile Router before
reaching CN2. Whereas, a packet following the direct path between reaching CN2. Whereas, a packet following the direct path between
them need not even leave the mobile network. Readers are referred to them need not even leave the mobile network. Readers are referred to
Appendix B.3 for detailed illustration of the resulting routing Appendix B.3 for detailed illustration of the resulting routing
paths. paths.
skipping to change at page 9, line 42 skipping to change at page 10, line 4
paths. paths.
Apart from the consequences of increased packet delay and packet size Apart from the consequences of increased packet delay and packet size
which are discussed in previous sub-sections, there are two which are discussed in previous sub-sections, there are two
additional effects that are undesirable: additional effects that are undesirable:
o when the nested mobile network is disconnected from the Internet o when the nested mobile network is disconnected from the Internet
(e.g. MR1 loses its egress connectivity), MNN and CN2 can no (e.g. MR1 loses its egress connectivity), MNN and CN2 can no
longer communicate with each other, even though the direct path longer communicate with each other, even though the direct path
from MNN to CN2 is unaffected; from MNN to CN2 is unaffected;
o the egress link(s) of the root Mobile Router (i.e. MR1) becomes a 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 bottleneck for all the traffic that is coming in and out of the
nested mobile network. nested mobile network.
A Route Optimization mechanism could allow traffic between two Mobile A Route Optimization mechanism could allow traffic between two Mobile
Network Nodes nested within the same mobile network to follow a Network Nodes nested within the same mobile network to follow a
direct path between them, without being routed out of the mobile direct path between them, without being routed out of the mobile
network. This may also off-load processing burden of the upstream network. This may also off-load the processing burden of the
Mobile Routers when the direct path between the two Mobile Network upstream Mobile Routers when the direct path between the two Mobile
Nodes does not traverse these Mobile Routers. Network Nodes does not traverse these Mobile Routers.
2.7 Deadlock with a Home Agent Nested in a Mobile Network 2.7. Stalemate with a Home Agent Nested in a Mobile Network
Several configurations for the Home Network are described in [6]. In Several configurations for the Home Network are described in [9]. In
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, that is further the mobile network is itself an aggregation of Mobile Network
subnetted in Mobile Network Prefixes, that are assigned to (children) Prefixes assigned to (children) Mobile Routers.
Mobile Routers.
A deadlock has been documented 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 can not Router visits one of its children. The child Mobile Router can not
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.
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
reach to the Internet is available at all. 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.
skipping to change at page 11, line 35 skipping to change at page 11, line 35
possibility of deadlock when Home Agents are nested within a mobile possibility of deadlock when Home Agents are nested within a mobile
network. 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 is an informational document that describes some limitations This document highlights some limitations of the NEMO Basic Support.
with NEMO Basic Support and does not introduce any additional In particular, some security concerns could prevent interesting
security concerns. Please see RFC3963 [1] for security applications of the protocol, as detailed in Section 2.5.
considerations pertaining to the NEMO Basic Support protocol.
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.
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. In addition,
sincere appreciation is also extended to Greg Daley, Erik Nordmark, sincere appreciation is also extended to Jari Arkko, Carlos
T.J. Kniveton, Alexandru Petrescu, Hesham Soliman, Ryuji Wakikawa and Bernardos, Greg Daley, T.J. Kniveton, Henrik Levkowetz, Erik
Nordmark, Alexandru Petrescu, Hesham Soliman, Ryuji Wakikawa and
Patrick Wetterwald for their various contributions. 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] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [2] Manner, J. and M. Kojo, "Mobility Related Terminology",
IPv6", RFC 3775, June 2004.
[3] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[4] 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-03 (work in progress),
February 2005. February 2005.
7.2. Informative Reference
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
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-04 (work in progress),
February 2005. February 2005.
[6] Thubert, P., "NEMO Home Network models", [6] Deering, S. and B. Zill, "Redundant Address Deletion when
draft-ietf-nemo-home-network-models-03 (work in progress),
March 2005.
7.2 Informative Reference
[7] 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.
[8] Petrescu, A., "Threats for Basic Network Mobility Support (NEMO [7] Petrescu, A., "Threats for Basic Network Mobility Support (NEMO
threats)", draft-petrescu-nemo-threats-01 (work in progress), threats)", draft-petrescu-nemo-threats-01 (work in progress),
January 2004. January 2004.
[9] Jung, S., "Threat Analysis on NEMO Basic Operations", [8] Jung, S., "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. July 2004.
Authors' Addresses [9] Thubert, P., "NEMO Home Network models",
draft-ietf-nemo-home-network-models-03 (work in progress),
Chan-Wah Ng March 2005.
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
SG
Phone: +65 65505420 [10] Draves, R., "Default Address Selection for Internet Protocol
Email: chanwah.ng@sg.panasonic.com version 6 (IPv6)", RFC 3484, February 2003.
Pascal Thubert Appendix A. Change Log
Cisco Systems Technology Center
Village d'Entreprises Green Side
400, Avenue Roumanille
Biot - Sophia Antipolis 06410
FRANCE
Email: pthubert@cisco.com o draft-ietf-nemo-ro-problem-statement-01:
Masafumi Watari * Added text on effect on TCP contributed by Carlos in Sect 2.1 -
KDDI R&D Laboratories Inc. "Sub-Optimality with NEMO Basic Support"
2-1-15 Ohara
Kamifukuoka, Saitama 356-8502
JAPAN
Email: watari@kddilabs.jp * Added text on VMN using CoA as source address in Appendix B.4.3
Fan Zhao * Re-written Section 2.5 - "Security Policy Prohibiting Traffic
University of California Davis From Visiting Nodes"
One Shields Avenue
Davis, CA 95616
US
Phone: +1 530 752 3128 * Replaced "deadlock" with "stalemate" in Section 2.7.
Email: fanzhao@ucdavis.edu
Appendix A. Change Log * Minor typographical corrections
o draft-ietf-nemo-ro-problem-statement-00: o draft-ietf-nemo-ro-problem-statement-00:
* Initial version adapted from Section 1 & 2 of * Initial version adapted from Section 1 & 2 of
'draft-thubert-nemo-ro-taxonomy-04.txt' 'draft-thubert-nemo-ro-taxonomy-04.txt'
* Added Section 2.2: Bottleneck in the Home Network * Added Section 2.2: Bottleneck in the Home Network
* Added Section 2.5: Security Policy Prohibiting Traffic From * Added Section 2.5: Security Policy Prohibiting Traffic From
Visiting Nodes Visiting Nodes
* 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 involves 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 cases. 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 [4], 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
cannot process Binding Updates sent by peers). cannot process Binding Updates sent by peers.
B.1 CN located in the fixed infrastructure B.1. CN located in the fixed infrastructure
The most typical configuration is the case where a Mobile Network The most typical configuration is the case where a Mobile Network
Node communicates with a Correspondent Node attached in the fixed Node communicates with a Correspondent Node attached in the fixed
infrastructure. Figure 3 below shows an example of such topology. infrastructure. Figure 3 below shows an example of such topology.
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| MR1_HA | | MR2_HA | | MR3_HA | | MR1_HA | | MR2_HA | | MR3_HA |
+---+----+ +---+----+ +---+----+ +---+----+ +---+----+ +---+----+
| | | | | |
+-------------------------+ +-------------------------+
skipping to change at page 16, line 5 skipping to change at page 16, line 5
| |
+---+---+ +---+---+
sub-MR | MR3 | sub-MR | MR3 |
+---+---+ +---+---+
| |
----+---- ----+----
MNN MNN
Figure 3: CN located at the infrastructure Figure 3: CN located at the infrastructure
B.1.1 Case A: LFN and standard IPv6 CN B.1.1. Case A: LFN and standard IPv6 CN
The simplest case is where both MNN and CN are fixed nodes with no 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 mobility functions. That is, MNN is a Local Fixed Node, and CN is a
standard IPv6 node. Packets are encapsulated between each Mobile standard IPv6 node. Packets are encapsulated between each Mobile
Router and its respective Home Agent. As shown in Figure 4, in such Router and its respective Home Agent. As shown in Figure 4, in such
case, the path between the two nodes would go through: case, the path between the two nodes 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
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
wouldn't go through the Home Agent of the Visiting Mobile Node nor wouldn't go through the Home Agent of the Visiting Mobile Node nor
the Home Agent of the Correspondent Node (not shown in the figure). the 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
B.1.3 Case C: VMN and standard IPv6 CN B.1.3. Case C: VMN and standard IPv6 CN
When the communication involves a Mobile IPv6 node either as a When the communication involves a Mobile IPv6 node either as a
Visiting Mobile Node or as a Correspondent Node, Mobile IPv6 route Visiting Mobile Node or as a Correspondent Node, Mobile IPv6 route
optimization cannot be performed because the standard IPv6 optimization cannot be performed because the standard IPv6
Correspondent Node cannot process Mobile IPv6 signaling. Therefore, Correspondent Node cannot process Mobile IPv6 signaling. Therefore,
MNN would establish a bi-directional tunnel with its HA, which causes 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 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 thus go through MNN's own Home Agent (VMN_HA). The path would
therefore be as shown on Figure 6: therefore be as shown on Figure 6:
skipping to change at page 17, line 19 skipping to change at page 17, line 18
| 3 | 3
1 2 | 1 2 |
CN --- VMN_HA --- MR3_HA CN --- VMN_HA --- MR3_HA
IPv6 Node IPv6 Node
Figure 6: MNN is a MIPv6 mobile node and CN is a standard IPv6 node Figure 6: MNN is a MIPv6 mobile node and CN is a standard IPv6 node
Providing Route Optimization involving a Mobile IPv6 node may require Providing Route Optimization involving a Mobile IPv6 node may require
optimization among the Mobile Routers and the Mobile IPv6 node. optimization among the Mobile Routers and the Mobile IPv6 node.
B.2 CN located in distinct nested NEMOs B.2. CN located in distinct nested NEMOs
The Correspondent Node may be located in another nested mobile The Correspondent Node may be located in another nested mobile
network, different from the one MNN is attached to, as shown on network, different from the one MNN is attached to, as shown in
Figure 7. We define such configuration as ``distinct nested mobile Figure 7. We define such configuration as "distinct nested mobile
networks.'' networks".
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+ +------+-+ +---+----+ +---+----+ +-+------+
\ | | / \ | | /
+--------+ +-------------------------+ +--------+ +--------+ +-------------------------+ +--------+
| MR1_HA |----| Internet |----| VMN_HA | | MR1_HA |----| Internet |----| VMN_HA |
+--------+ +-------------------------+ +--------+ +--------+ +-------------------------+ +--------+
| | | |
+---+---+ +---+---+ +---+---+ +---+---+
skipping to change at page 18, line 5 skipping to change at page 18, line 5
| | | |
+---+---+ ----+---- +---+---+ ----+----
sub-MR | MR3 | CN sub-MR | MR3 | CN
+---+---+ +---+---+
| |
----+---- ----+----
MNN MNN
Figure 7: MNN and CN located in distinct nested NEMOs Figure 7: MNN and CN located in distinct nested NEMOs
B.2.1 Case D: LFN and standard IPv6 CN B.2.1. Case D: LFN and standard IPv6 CN
Similar with Case A, we start off with the case where both end nodes Similar with Case A, we start off with the case where both end nodes
do not have any mobility functions. Packets are encapsulated at do not have any mobility functions. Packets are encapsulated at
every mobile router on the way out the nested mobile network, every mobile router on the way out the nested mobile network,
decapsulated by the Home Agents and then encapsulated again on its decapsulated by the Home Agents and then encapsulated again on its
way down the nested mobile network. way down the nested mobile network.
1 2 3 4 3 2 1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN | LFN |
| 1 | 1
1 2 3 2 | 1 2 3 2 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA
IPv6 Node IPv6 Node
Figure 8: MNN and CN are standard IPv6 nodes Figure 8: MNN and CN are standard IPv6 nodes
B.2.2 Case E: VMN and MIPv6 CN B.2.2. Case E: VMN and MIPv6 CN
Similar with Case B, when both end nodes are Mobile IPv6 nodes, the Similar with Case B, when both end nodes are Mobile IPv6 nodes, the
two nodes may initiate Mobile IPv6 route optimization. Again, two nodes may initiate Mobile IPv6 route optimization. Again,
packets will not go through the Home Agent of the MNN nor the Home packets will not go through the Home Agent of the MNN nor the Home
Agent of the Mobile IPv6 Correspondent Node (not shown in the Agent of the Mobile IPv6 Correspondent Node (not shown in the
figure). However, packets will still be tunneled for each Mobile figure). However, packets will still be tunneled for each Mobile
Router to its Home Agent and vise versa. Therefore, the path between Router to its Home Agent and vise versa. Therefore, the path between
MNN and CN would go through: MNN and CN would go through:
1 2 3 4 3 2 1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN | VMN |
| 1 | 1
1 2 3 2 | 1 2 3 2 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA
MIPv6 Node MIPv6 Node
Figure 9: MNN and CN are MIPv6 mobile nodes Figure 9: MNN and CN are MIPv6 mobile nodes
B.2.3 Case F: VMN and standard IPv6 CN B.2.3. Case F: VMN and standard IPv6 CN
Similar to Case C, when the communication involves a Mobile IPv6 node Similar to Case C, when the communication involves a Mobile IPv6 node
either as a Visiting Mobile Node or as a Correspondent Node, MIPv6 either as a Visiting Mobile Node or as a Correspondent Node, MIPv6
route optimization can not be performed because the standard IPv6 route optimization can not be performed because the standard IPv6
Correspondent Node cannot process Mobile IPv6 signaling. MNN would Correspondent Node cannot process Mobile IPv6 signaling. MNN would
therefore establish a bi-directional tunnel with its Home Agent. therefore establish a bi-directional tunnel with its Home Agent.
Packets between MNN and CN would thus go through MNN's own Home Agent Packets between MNN and CN would thus go through MNN's own Home Agent
as shown on figure Figure 10: as shown on figure Figure 10:
2 3 4 5 4 3 2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN | VMN |
| 2 | 2
1 2 3 2 1 | 1 2 3 2 1 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA --- VMN_HA CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA --- VMN_HA
IPv6 Node IPv6 Node
Figure 10: MNN is a MIPv6 mobile node and CN is a standard IPv6 node Figure 10: MNN is a MIPv6 mobile node and CN is a standard IPv6 node
B.3 CN and MNN located in the same nested NEMO B.3. CN and MNN located in the same nested NEMO
Figure 11 below shows the case where the two communicating nodes are Figure 11 below shows the case where the two communicating nodes are
connected behind different Mobile Routers that are connected in the connected behind different Mobile Routers that are connected in the
same nested mobile network, and thus behind the same root Mobile same nested mobile network, and thus behind the same root Mobile
Router. Route optimization can avoid packets being tunneled outside Router. Route optimization can avoid packets being tunneled outside
the nested mobile network. the nested mobile network.
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+ +------+-+ +---+----+ +---+----+ +-+------+
skipping to change at page 20, line 27 skipping to change at page 20, line 4
+-------+ +-------+ +-------+ +-------+
sub-MR | MR2 | | MR4 | sub-MR | MR2 | | MR4 |
+---+---+ +---+---+ +---+---+ +---+---+
| | | |
+---+---+ +---+---+ +---+---+ +---+---+
sub-MR | MR3 | | MR5 | sub-MR | MR3 | | MR5 |
+---+---+ +---+---+ +---+---+ +---+---+
| | | |
----+---- ----+---- ----+---- ----+----
MNN CN MNN CN
Figure 11: CN and MNN located in the same nested NEMO Figure 11: CN and MNN located in the same nested NEMO
B.3.1 Case G: LFN and standard IPv6 CN B.3.1. Case G: LFN and standard IPv6 CN
Again, we start off with the case where both end nodes do not have Again, we start off with the case where both end nodes do not have
any mobility functions. Packets are encapsulated at every Mobile any mobility functions. Packets are encapsulated at every Mobile
Router on the way out the nested mobile network via the root Mobile Router on the way out the nested mobile network via the root Mobile
Router, decapsulated and encapsulated by the Home Agents and then Router, decapsulated and encapsulated by the Home Agents and then
make their way back to the nested mobile network through the same make their way back to the nested mobile network through the same
root Mobile Router. Therefore, the path between MNN and CN would go root Mobile Router. Therefore, the path between MNN and CN would go
through: through:
1 2 3 4 3 2 1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN | LFN |
| 1 | 1
1 2 3 4 3 2 | 1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
IPv6 Node IPv6 Node
Figure 12: MNN and CN are standard IPv6 nodes Figure 12: MNN and CN are standard IPv6 nodes
B.3.2 Case H: VMN and MIPv6 CN B.3.2. Case H: VMN and MIPv6 CN
Similar with Case B and E, when both end nodes are Mobile IPv6 nodes, Similar with Case B and E, when both end nodes are Mobile IPv6 nodes,
the two nodes may initiate Mobile IPv6 route optimization which will the two nodes may initiate Mobile IPv6 route optimization which will
avoid the packets to go through the Home Agent of MNN nor the Home avoid the packets to go through the Home Agent of MNN nor the Home
Agent of the Mobile IPv6 CN (not shown in the figure). However, Agent of the Mobile IPv6 CN (not shown in the figure). However,
packets will still be tunneled between each Mobile Router and its packets will still be tunneled between each Mobile Router and its
respective Home Agent in both directions. Therefore, the path would respective Home Agent in both directions. Therefore, the path would
be the same with Case G and go through: be the same with Case G and go through:
1 2 3 4 3 2 1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN | LFN |
| 1 | 1
1 2 3 4 3 2 | 1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
MIPv6 Node MIPv6 Node
Figure 13: MNN and CN are MIPv6 mobile nodes Figure 13: MNN and CN are MIPv6 mobile nodes
B.3.3 Case I: VMN and standard IPv6 CN B.3.3. Case I: VMN and standard IPv6 CN
As for Case C and Case F, when the communication involves a Mobile As for Case C and Case F, when the communication involves a Mobile
IPv6 node either as a Visiting Mobile Node or as a Correspondent IPv6 node either as a Visiting Mobile Node or as a Correspondent
Node, Mobile IPv6 Route Optimization can not be performed. Node, Mobile IPv6 Route Optimization can not be performed.
Therefore, MNN will establish a bi-directional tunnel with its Home Therefore, MNN will establish a bi-directional tunnel with its Home
Agent. Packets between MNN and CN would thus go through MNN's own Agent. Packets between MNN and CN would thus go through MNN's own
Home Agent. The path would therefore be as shown on Figure 14: Home Agent. The path would therefore be as shown on Figure 14:
2 3 4 5 4 3 2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
skipping to change at page 22, line 5 skipping to change at page 21, line 28
| |
VMN_HA VMN_HA
| |
| 1 | 1
1 2 3 4 3 2 | 1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
IPv6 Node IPv6 Node
Figure 14: MNN is a MIPv6 mobile node and CN is a standard IPv6 node Figure 14: MNN is a MIPv6 mobile node and CN is a standard IPv6 node
B.4 CN located behind the same nested MR B.4. CN located behind the same nested MR
Figure 15 below shows the case where the two communicating nodes are Figure 15 below shows the case where the two communicating nodes are
connected behind the same nested Mobile Router. The optimization is connected behind the same nested Mobile Router. The optimization is
required when the communication involves MIPv6-enabled nodes. required when the communication involves MIPv6-enabled nodes.
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+ +------+-+ +---+----+ +---+----+ +-+------+
\ | | / \ | | /
+--------+ +-------------------------+ +--------+ +--------+ +-------------------------+ +--------+
skipping to change at page 22, line 36 skipping to change at page 22, line 30
| |
+---+---+ +---+---+
sub-MR | MR3 | sub-MR | MR3 |
+---+---+ +---+---+
| |
-+--+--+- -+--+--+-
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 communication. 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
Similar with Case H, when both end nodes are Mobile IPv6 nodes, the Similar with Case H, when both end nodes are Mobile IPv6 nodes, the
two nodes may initiate Mobile IPv6 route optimization. Although few two nodes may initiate Mobile IPv6 route optimization. Although few
packets would go out the nested mobile network for the Return packets would go out the nested mobile network for the Return
Routability initialization, however, unlike Case B and Case E, Routability initialization, however, unlike Case B and Case E,
packets will not get tunneled outside the nested mobile network. packets will not get tunneled outside the nested mobile network.
Therefore, packets between MNN and CN would eventually go through: Therefore, packets between MNN and CN would eventually go through:
1 1
MNN --- CN MNN --- CN
VMN MIPv6 Node VMN MIPv6 Node
Figure 17: MNN and CN are MIPv6 mobile nodes Figure 17: MNN and CN are MIPv6 mobile nodes
If the root Mobile Router is disconnected while the nodes exchange If the root Mobile Router is disconnected while the nodes exchange
keys for the Return Routability procedure, they may not communicate keys for the Return Routability procedure, they may not communicate
even though they are connected on the same link. even though they are connected on the same link.
B.4.3 Case L: VMN and standard IPv6 CN B.4.3. Case L: VMN and standard IPv6 CN
When the communication involves a Mobile IPv6 node either as a When the communication involves a Mobile IPv6 node either as a
Visiting Mobile Network Node or as a Correspondent Node, Mobile IPv6 Visiting Mobile Network Node or as a Correspondent Node, Mobile IPv6
Route Optimization cannot be performed. Therefore, even though the Route Optimization cannot be performed. Therefore, even though the
two nodes are on the same link, MNN will establish a bi-directional 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 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 nested mobile network. Path between MNN and CN would require another
Home Agent (VMN_HA) to go through for this Mobile IPv6 node: Home Agent (VMN_HA) to go through for this Mobile IPv6 node:
2 3 4 5 4 3 2 3 4 5 4 3
skipping to change at page 24, line 5 skipping to change at page 23, line 39
| |
VMN_HA VMN_HA
| |
| 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
address of the packets, thus avoiding the tunneling with the MNN's
Home Agent. This is particularly useful for a short-term
communication that may easily be retried if it fails. Default
Address Selection [10] provides some mechanisms for controlling the
choice of the source address.
Authors' Addresses
Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
SG
Phone: +65 65505420
Email: chanwah.ng@sg.panasonic.com
Pascal Thubert
Cisco Systems Technology Center
Village d'Entreprises Green Side
400, Avenue Roumanille
Biot - Sophia Antipolis 06410
FRANCE
Email: pthubert@cisco.com
Masafumi Watari
KDDI R&D Laboratories Inc.
2-1-15 Ohara
Fujimino, Saitama 356-8502
JAPAN
Email: watari@kddilabs.jp
Fan Zhao
University of California Davis
One Shields Avenue
Davis, CA 95616
US
Phone: +1 530 752 3128
Email: fanzhao@ucdavis.edu
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 73 change blocks. 
173 lines changed or deleted 199 lines changed or added

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