NEMO Working Group                                                 C. Ng
Internet-Draft                                  Panasonic Singapore Labs
Expires: January 5, April 14, 2006                                       P. Thubert
                                                           Cisco Systems
                                                               M. Watari
                                                           KDDI R&D Labs
                                                                 F. Zhao
                                                                UC Davis
                                                            July 4,
                                                        October 11, 2005

         Network Mobility Route Optimization Problem Statement
                draft-ietf-nemo-ro-problem-statement-00
                draft-ietf-nemo-ro-problem-statement-01

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 January 5, April 14, 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
   Agent 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 (RO) for NEMO.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  NEMO Route Optimization Problem Statement  . . . . . . . . . .  4
     2.1
     2.1.  Sub-Optimality with NEMO Basic Support . . . . . . . . . .  4
     2.2
     2.2.  Bottleneck in Home Network . . . . . . . . . . . . . . . .  6
     2.3
     2.3.  Amplified Sub-Optimality in Nested Mobile Networks . . . .  6
     2.4
     2.4.  Sub-Optimality with Combined Mobile IPv6 Route
           Optimization . . . . . . . . . . . . . . . . . . . . . . .  8
     2.5
     2.5.  Security Policy Prohibiting Traffic From Visiting Nodes  .  8
     2.6  9
     2.6.  Instability of Communications within a Nested Mobile
           Network  . . . . . . . . . . . . . . . . . . . . . . . . .  9
     2.7   Deadlock
     2.7.  Stalemate with a Home Agent Nested in a Mobile Network . . 10
   3.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11 12
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     7.1 13
     7.1.  Normative Reference  . . . . . . . . . . . . . . . . . . . 12
     7.2 13
     7.2.  Informative Reference  . . . . . . . . . . . . . . . . . . 12
       Authors' Addresses . . . . . . . . 13
   Appendix A.  Change Log  . . . . . . . . . . . . . . 13
   A.  Change Log . . . . . . . 14
   Appendix B.  Various configurations involving Nested Mobile
                Networks  . . . . . . . . . . . . . . . . . . . 14
   B.  Various configurations involving Nested Mobile Networks . . . 15
     B.1
     B.1.  CN located in the fixed infrastructure . . . . . . . . . . 15
       B.1.1
       B.1.1.  Case A: LFN and standard IPv6 CN . . . . . . . . . . . 16
       B.1.2
       B.1.2.  Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . 16
       B.1.3
       B.1.3.  Case C: VMN and standard IPv6 CN . . . . . . . . . . . 16
     B.2
     B.2.  CN located in distinct nested NEMOs  . . . . . . . . . . . 17
       B.2.1
       B.2.1.  Case D: LFN and standard IPv6 CN . . . . . . . . . . . 18
       B.2.2
       B.2.2.  Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . 18
       B.2.3
       B.2.3.  Case F: VMN and standard IPv6 CN . . . . . . . . . . . 18
     B.3
     B.3.  CN and MNN located in the same nested NEMO . . . . . . . . 19
       B.3.1
       B.3.1.  Case G: LFN and standard IPv6 CN . . . . . . . . . . . 20
       B.3.2
       B.3.2.  Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . 21
       B.3.3 20
       B.3.3.  Case I: VMN and standard IPv6 CN . . . . . . . . . . . 21
     B.4
     B.4.  CN located behind the same nested MR . . . . . . . . . . . 22
       B.4.1 21
       B.4.1.  Case J: LFN and standard IPv6 CN . . . . . . . . . . . 22
       B.4.2
       B.4.2.  Case K: VMN and MIPv6 CN . . . . . . . . . . . . . . . 23
       B.4.3 22
       B.4.3.  Case L: VMN and standard IPv6 CN . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
   Intellectual Property and Copyright Statements . . . . . . . . 24 . . 25

1.  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 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 at all time, , 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 [2] [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 [2][3], [4][2], NEMO related terms defined in [4], [3], and
   NEMO goals and requirements [5].

2.  NEMO Route Optimization Problem Statement

   In essence, the goal of Route Optimization in NEMO is to reduce
   limitations and sub-optimalities introduced by the bi-directional
   tunnel between a Mobile Router and its Home Agent (also known as the
   MRHA tunnel).  In the following sub-sections, we will describe the
   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
   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 deadlock
   situation when a Home Agent is part of a mobile network.

2.1

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 sub-optimal path between the two nodes.  This
   sub-optimality has the following undesirable 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 higher longer than if the packet were to go straight
      from the mobile network to the Correspondent Node.  In the best
      case, where  When the
      Correspondent Node (or the mobile network) resides near the Home
      Agent, the increase in packet delay is minimal.  In
      the worst case, where 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 tremendous. 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
      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 packets 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, consider given a voice application using a 8kbps
      algorithm (e.g.  G.729) and taking a voice sample every 20ms (as
      in RFC 1889).  The 1889), the packet transmission rate will be 50 packets per
      second.  IPv6/UDP/RTP header cause an overhead of 384 bits (i.e.
      19200bps of overhead).  Each additional IPv6 header is an extra
      16kpbs, 320 bits per
      packet (i.e. 16kbps), which is twice the actual payload. 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.

2.2

2.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

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 sub-optimal routing 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.

               +--------+  +--------+  +--------+  +--------+
               | MR2_HA |  | MR3_HA |  | MR4_HA |  | MR5_HA |
               +------+-+  +---+----+  +---+----+  +-+------+
                       \       |           |        /
        +--------+    +------------------------------+
        | MR1_HA |----|         Internet             |-----CN1
        +--------+    +------------------------------+
                                    |
                                +---+---+
                      root-MR   |  MR1  |
                                +-------+
                                 |     |
                          +-------+   +-------+
                 sub-MR   |  MR2  |   |  MR4  |
                          +---+---+   +---+---+
                              |           |
                          +---+---+   +---+---+
                 sub-MR   |  MR3  |   |  MR5  |
                          +---+---+   +---+---+
                              |           |
                          ----+----   ----+----
                             MNN         CN2

   Figure 1: An example of nested Mobile Network

   Using NEMO Basic Support, the flow of packets between a Mobile
   Network Node, MNN, and a Correspondent Node, CN1, would need to go
   through three separate tunnels, illustrated in Figure 2 below.

                                ----------.
                      ---------/         /----------.
              -------/        |         |          /-------
    MNN -----( -  - | -  -  - | -  -  - | -  -  - |  -  - (------ CN1
           MR3-------\        |         |          \-------MR3_HA
                    MR2--------\         \----------MR2_HA
                              MR1---------MR1_HA

   Figure 2: Nesting of Bi-Directional Tunnels
   This leads to the following problems:

   o  Sub-optimal routing

      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 [7] [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

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 [2] [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.

2.5

2.5.  Security Policy Prohibiting Traffic From Visiting Nodes

   The ability of Mobile Routers to attach to other Mobile Routers
   allows the possibility for them to form a mesh that extends the
   infrastructure dynamically, relaying each others packets to the
   Internet.  By providing reachability to one another, they cooperate
   to improve the network availability for all parties.  When Mobile
   Routers have no prior knowledge of their peers (no Security
   association, AAA, PKI etc...) it can still be mutually beneficial to
   apply a form of reciprocal altruism based on anonymity and
   innocuousness.  In particular, it is possible to adopt a tit for tat
   (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
   visitor 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 Router's binding by rogue visitors have been documented in [8][9]).  As a consequence, it can be expected that
   [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 deployments, deployment scenarios,
   policies will be put in place to prevent untrusted
   visitors unauthorized Visiting Mobile
   Nodes from attaching to the Mobile Router.  This will block T4T

   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 for developing widely. 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 would prevent the multiple re-
   encapsulation of the packets by nested allows traffic from Mobile Routers might as a side
   effect alleviate this limitation and leave the way
   Network Nodes to by-pass the bi-directional tunnel between a more open Mobile
   Router and
   efficient model 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 fringe of the Internet.

2.6
   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;
   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  Deadlock

2.7.  Stalemate with a Home Agent Nested in a Mobile Network

   Several configurations for the Home Network are described in [6]. [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, that is further
   subnetted in aggregation of Mobile Network Prefixes, that are
   Prefixes assigned to (children) Mobile Routers.

   A deadlock has been documented stalemate situation exists in the case where the parent Mobile
   Router visits one of its children.  The child Mobile Router can not 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.

   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
   reach to the
   Internet is available at all. reachable or not.

3.  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 effects of sub-optimal routing with NEMO Basic
   Support, how it 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 deadlock 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 is an informational document that describes highlights some limitations
   with of the NEMO Basic Support and does not introduce any additional Support.
   In particular, some security concerns.  Please see RFC3963 [1] concerns could prevent interesting
   applications of the protocol, as detailed in Section 2.5.

   Route Optimization for security
   considerations pertaining to RFC 3963 [1] might introduce new threats, just
   as it might alleviate existing ones.  This aspect will certainly be a
   key criterion in the NEMO Basic Support protocol. evaluation of the proposed solutions.

6.  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.  In addition,
   sincere appreciation is also extended to Jari Arkko, Carlos
   Bernardos, Greg Daley, Erik Nordmark, T.J. Kniveton, Henrik Levkowetz, Erik
   Nordmark, Alexandru Petrescu, Hesham Soliman, Ryuji Wakikawa and
   Patrick Wetterwald for their various contributions.

7.  References

7.1

7.1.  Normative Reference

   [1]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
        "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
        January 2005.

   [2]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
        IPv6", RFC 3775, June 2004.

   [3]  Manner, J. and M. Kojo, "Mobility Related Terminology",
        RFC 3753, June 2004.

   [4]

   [3]  Ernst, T. and H. Lach, "Network Mobility Support Terminology",
        draft-ietf-nemo-terminology-03 (work in progress),
        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",
         draft-ietf-nemo-requirements-04 (work in progress),
         February 2005.

   [6]  Thubert, P., "NEMO Home Network models",
        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",
         draft-deering-ipv6-encap-addr-deletion-00 (work in progress),
         November 2001.

   [8]

   [7]   Petrescu, A., "Threats for Basic Network Mobility Support (NEMO
         threats)", draft-petrescu-nemo-threats-01 (work in progress),
         January 2004.

   [9]

   [8]   Jung, S., "Threat Analysis on NEMO Basic Operations",
        draft-jung-nemo-threat-analysis-02 (work Operations",
         draft-jung-nemo-threat-analysis-02 (work in progress),
         July 2004.

   [9]   Thubert, P., "NEMO Home Network models",
         draft-ietf-nemo-home-network-models-03 (work in progress),
         March 2005.

   [10]  Draves, R., "Default Address Selection for Internet Protocol
         version 6 (IPv6)", RFC 3484, February 2003.

Appendix A.  Change Log

   o  draft-ietf-nemo-ro-problem-statement-01:

      *  Added text on effect on TCP contributed by Carlos in Sect 2.1 -
         "Sub-Optimality with NEMO Basic Support"

      *  Added text on VMN using CoA as source address in progress),
        July 2004.

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
   Kamifukuoka, 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 Appendix A.  Change Log B.4.3

      *  Re-written Section 2.5 - "Security Policy Prohibiting Traffic
         From Visiting Nodes"

      *  Replaced "deadlock" with "stalemate" in Section 2.7.

      *  Minor typographical corrections

   o  draft-ietf-nemo-ro-problem-statement-00:

      *  Initial version adapted from Section 1 & 2 of
         'draft-thubert-nemo-ro-taxonomy-04.txt'

      *  Added Section 2.2: Bottleneck in the Home Network

      *  Added Section 2.5: Security Policy Prohibiting Traffic From
         Visiting Nodes

      *  Added Section 2.7: Deadlock with a Home Agent Nested in a
         Mobile Network

      *  Appendix B extracted from 'draft-watari-nemo-nested-cn-01.txt'

Appendix B.  Various configurations involving Nested Mobile Networks

   In the following sections, we try to describe different communication
   models which involves involve a nested mobile network, and to clarify the
   issues for each cases.  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 [4], [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 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

B.1.1

B.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

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
   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).
   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

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:

               2       3       4       5          4
          MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA
          VMN                                           |
                                                        | 3
                                       1          2     |
                                   CN --- VMN_HA --- MR3_HA
                                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
   optimization among the Mobile Routers and the Mobile IPv6 node.

B.2

B.2.  CN located in distinct nested NEMOs

   The Correspondent Node may be located in another nested mobile
   network, different from the one MNN is attached to, as shown on in
   Figure 7.  We define such configuration as ``distinct "distinct nested mobile
   networks.''
   networks".

              +--------+  +--------+  +--------+  +--------+
              | MR2_HA |  | MR3_HA |  | MR4_HA |  | MR5_HA |
              +------+-+  +---+----+  +---+----+  +-+------+
                      \       |           |        /
         +--------+    +-------------------------+    +--------+
         | MR1_HA |----|        Internet         |----| VMN_HA |
         +--------+    +-------------------------+    +--------+
                          |                   |
                      +---+---+           +---+---+
            root-MR   |  MR1  |           |  MR4  |
                      +---+---+           +---+---+
                          |                   |
                      +---+---+           +---+---+
             sub-MR   |  MR2  |           |  MR5  |
                      +---+---+           +---+---+
                          |                   |
                      +---+---+           ----+----
             sub-MR   |  MR3  |              CN
                      +---+---+
                          |
                      ----+----
                         MNN

   Figure 7: MNN and CN located in distinct nested NEMOs

B.2.1

B.2.1.  Case D: LFN and standard IPv6 CN

   Similar with Case A, we start off with the case where both end nodes
   do not have any mobility functions.  Packets are encapsulated at
   every mobile router on the way out the nested mobile network,
   decapsulated by the Home Agents and then encapsulated again on its
   way down the nested mobile network.

            1       2       3       4          3          2
       MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
       LFN                                                      |
                                                                | 1
                               1       2       3          2     |
                           CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA
                        IPv6 Node

   Figure 8: MNN and CN are standard IPv6 nodes

B.2.2

B.2.2.  Case E: VMN and MIPv6 CN

   Similar with Case B, when both end nodes are Mobile IPv6 nodes, the
   two nodes may initiate Mobile IPv6 route optimization.  Again,
   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
   figure).  However, packets will still be tunneled for each Mobile
   Router to its Home Agent and vise versa.  Therefore, the path between
   MNN and CN would go through:

            1       2       3       4          3          2
       MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
       VMN                                                      |
                                                                | 1
                               1       2       3          2     |
                           CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA
                       MIPv6 Node

   Figure 9: MNN and CN are MIPv6 mobile nodes

B.2.3

B.2.3.  Case F: VMN and standard IPv6 CN

   Similar to Case C, when the communication involves a Mobile IPv6 node
   either as a Visiting Mobile Node or as a Correspondent Node, MIPv6
   route optimization can not be performed because the standard IPv6
   Correspondent Node cannot process Mobile IPv6 signaling.  MNN would
   therefore establish a bi-directional tunnel with its Home Agent.
   Packets between MNN and CN would thus go through MNN's own Home Agent
   as shown on figure Figure 10:

            2       3       4       5          4          3
       MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
       VMN                                                      |
                                                                | 2
                   1       2       3           2          1     |
               CN --- MR5 --- MR4 --- MR4_HA  --- MR5_HA --- VMN_HA
            IPv6 Node

   Figure 10: MNN is a MIPv6 mobile node and CN is a standard IPv6 node

B.3

B.3.  CN and MNN located in the same nested NEMO

   Figure 11 below shows the case where the two communicating nodes are
   connected behind different Mobile Routers that are connected in the
   same nested mobile network, and thus behind the same root Mobile
   Router.  Route optimization can avoid packets being tunneled outside
   the nested mobile network.

              +--------+  +--------+  +--------+  +--------+
              | MR2_HA |  | MR3_HA |  | MR4_HA |  | MR5_HA |
              +------+-+  +---+----+  +---+----+  +-+------+
                      \       |           |        /
         +--------+    +-------------------------+    +--------+
         | MR1_HA |----|        Internet         |----| VMN_HA |
         +--------+    +-------------------------+    +--------+
                                    |
                                +---+---+
                      root-MR   |  MR1  |
                                +-------+
                                 |     |
                          +-------+   +-------+
                 sub-MR   |  MR2  |   |  MR4  |
                          +---+---+   +---+---+
                              |           |
                          +---+---+   +---+---+
                 sub-MR   |  MR3  |   |  MR5  |
                          +---+---+   +---+---+
                              |           |
                          ----+----   ----+----
                             MNN          CN
   Figure 11: CN and MNN located in the same nested NEMO

B.3.1

B.3.1.  Case G: LFN and standard IPv6 CN

   Again, we start off with the case where both end nodes do not have
   any mobility functions.  Packets are encapsulated at every Mobile
   Router on the way out the nested mobile network via the root Mobile
   Router, decapsulated and encapsulated by the Home Agents and then
   make their way back to the nested mobile network through the same
   root Mobile Router.  Therefore, the path between MNN and CN would go
   through:

            1       2       3       4          3          2
       MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
       LFN                                                      |
                                                                | 1
            1       2       3       4          3          2     |
        CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
     IPv6 Node

   Figure 12: MNN and CN are standard IPv6 nodes

B.3.2

B.3.2.  Case H: VMN and MIPv6 CN

   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
   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,
   packets will still be tunneled between each Mobile Router and its
   respective Home Agent in both directions.  Therefore, the path would
   be the same with Case G and go through:

             1       2       3       4          3          2
        MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
        LFN                                                      |
                                                                 | 1
             1       2       3       4          3          2     |
         CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
     MIPv6 Node

   Figure 13: MNN and CN are MIPv6 mobile nodes

B.3.3

B.3.3.  Case I: VMN and standard IPv6 CN

   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
   Node, Mobile IPv6 Route Optimization can not be performed.
   Therefore, MNN will establish a bi-directional tunnel with its Home
   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:

            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 --- MR4_HA --- MR5_HA
      IPv6 Node

   Figure 14: MNN is a MIPv6 mobile node and CN is a standard IPv6 node

B.4

B.4.  CN located behind the same nested MR

   Figure 15 below shows the case where the two communicating nodes are
   connected behind the same nested Mobile Router.  The optimization is
   required when the communication involves MIPv6-enabled nodes.

              +--------+  +--------+  +--------+  +--------+
              | MR2_HA |  | MR3_HA |  | MR4_HA |  | MR5_HA |
              +------+-+  +---+----+  +---+----+  +-+------+
                      \       |           |        /
         +--------+    +-------------------------+    +--------+
         | MR1_HA |----|        Internet         |----| VMN_HA |
         +--------+    +-------------------------+    +--------+
                                    |
                                +---+---+
                      root-MR   |  MR1  |
                                +---+---+
                                    |
                                +-------+
                       sub-MR   |  MR2  |
                                +---+---+
                                    |
                                +---+---+
                       sub-MR   |  MR3  |
                                +---+---+
                                    |
                                -+--+--+-
                                MNN    CN

   Figure 15: MNN and CN located behind the same nested MR

B.4.1

B.4.1.  Case J: LFN and standard IPv6 CN

   If both end nodes are Local Fixed Nodes, no special function is
   necessary for optimization of their communication.  The path between
   the two nodes would go through:

                                  1
                             MNN --- CN
                             LFN   IPv6 Node

   Figure 16: MNN and CN are standard IPv6 nodes

B.4.2

B.4.2.  Case K: VMN and MIPv6 CN

   Similar with Case H, when both end nodes are Mobile IPv6 nodes, the
   two nodes may initiate Mobile IPv6 route optimization.  Although few
   packets would go out the nested mobile network for the Return
   Routability initialization, however, unlike Case B and Case E,
   packets will not get tunneled outside the nested mobile network.
   Therefore, packets between MNN and CN would eventually go through:

                                  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

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
   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

   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.