doc: Add RFC documents

1 files changed, 1459 insertions, 0 deletions

diff --git a/doc/rfc/rfc4888.txt b/doc/rfc/rfc4888.txt
new file mode 100644
index 0000000..8a0ca9b
--- /dev/null
+++ b/doc/rfc/rfc4888.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group                                              C. Ng
+Request for Comments: 4888                      Panasonic Singapore Labs
+Category: Informational                                       P. Thubert
+                                                           Cisco Systems
+                                                               M. Watari
+                                                           KDDI R&D Labs
+                                                                 F. Zhao
+                                                                UC Davis
+                                                               July 2007
+
+
+         Network Mobility Route Optimization Problem Statement
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+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 sub-optimal routing
+   results in various inefficiencies associated with packet delivery,
+   such as increased delay and bottleneck links leading to traffic
+   congestion, which can ultimately disrupt all communications to and
+   from the Mobile Network Nodes.  Additionally, with nesting of Mobile
+   Networks, these inefficiencies get compounded, and stalemate
+   conditions may occur in specific dispositions.  This document
+   investigates such problems and provides the motivation behind Route
+   Optimization (RO) for NEMO.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ng, et al.                   Informational                      [Page 1]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  NEMO Route Optimization Problem Statement  . . . . . . . . . .  3
+     2.1.  Sub-Optimality with NEMO Basic Support . . . . . . . . . .  4
+     2.2.  Bottleneck in the Home Network . . . . . . . . . . . . . .  6
+     2.3.  Amplified Sub-Optimality in Nested Mobile Networks . . . .  6
+     2.4.  Sub-Optimality with Combined Mobile IPv6 Route
+           Optimization . . . . . . . . . . . . . . . . . . . . . . .  8
+     2.5.  Security Policy Prohibiting Traffic from Visiting Nodes  .  9
+     2.6.  Instability of Communications within a Nested Mobile
+           Network  . . . . . . . . . . . . . . . . . . . . . . . . .  9
+     2.7.  Stalemate with a Home Agent Nested in a Mobile Network . . 10
+   3.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
+   5.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
+   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     6.1.  Normative Reference  . . . . . . . . . . . . . . . . . . . 12
+     6.2.  Informative Reference  . . . . . . . . . . . . . . . . . . 12
+   Appendix A.  Various Configurations Involving Nested Mobile
+                Networks  . . . . . . . . . . . . . . . . . . . . . . 13
+     A.1.  CN Located in the Fixed Infrastructure . . . . . . . . . . 13
+       A.1.1.  Case A: LFN and Standard IPv6 CN . . . . . . . . . . . 14
+       A.1.2.  Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . 14
+       A.1.3.  Case C: VMN and Standard IPv6 CN . . . . . . . . . . . 14
+     A.2.  CN Located in Distinct Nested NEMOs  . . . . . . . . . . . 15
+       A.2.1.  Case D: LFN and Standard IPv6 CN . . . . . . . . . . . 16
+       A.2.2.  Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . 16
+       A.2.3.  Case F: VMN and Standard IPv6 CN . . . . . . . . . . . 16
+     A.3.  MNN and CN Located in the Same Nested NEMO . . . . . . . . 17
+       A.3.1.  Case G: LFN and Standard IPv6 CN . . . . . . . . . . . 18
+       A.3.2.  Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . 18
+       A.3.3.  Case I: VMN and Standard IPv6 CN . . . . . . . . . . . 19
+     A.4.  CN Located Behind the Same Nested MR . . . . . . . . . . . 19
+       A.4.1.  Case J: LFN and Standard IPv6 CN . . . . . . . . . . . 20
+       A.4.2.  Case K: VMN and MIPv6 CN . . . . . . . . . . . . . . . 20
+       A.4.3.  Case L: VMN and Standard IPv6 CN . . . . . . . . . . . 21
+   Appendix B.  Example of How a Stalemate Situation Can Occur  . . . 22
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ng, et al.                   Informational                      [Page 2]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+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 (also known as the MRHA tunnel) when the mobile
+   network is away.  Although such an arrangement allows Mobile Network
+   Nodes to reach and be reached by any node on the Internet,
+   limitations associated to the base protocol degrade overall
+   performance of the network and, ultimately, can prevent all
+   communications to and from the Mobile Network Nodes.
+
+   Some of these concerns already exist with Mobile IPv6 [4] and were
+   addressed by the mechanism known as Route Optimization, which is part
+   of the base protocol.  With Mobile IPv6, Route Optimization mostly
+   improves the end-to-end path between the 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 that readers are familiar with general terminologies related
+   to mobility in [4][2], NEMO-related terms defined in [3], and NEMO
+   goals and requirements [5].
+
+2.  NEMO Route Optimization Problem Statement
+
+   Given the NEMO Basic Support protocol, all data packets to and from
+   Mobile Network Nodes must go through the Home Agent, even though a
+   shorter path may exist between the Mobile Network Node and its
+   Correspondent Node.  In addition, with the nesting of Mobile Routers,
+   these data packets must go through multiple Home Agents and several
+   levels of encapsulation, which may be avoided.  This results in
+   various inefficiencies and problems with packet delivery, which can
+   ultimately disrupt all communications to and from the Mobile Network
+   Nodes.
+
+   In the following sub-sections, we will describe the effects of a
+   pinball route with NEMO Basic Support, how it may cause a bottleneck
+   to be formed in the Home Network, and how these get amplified with
+
+
+
+Ng, et al.                   Informational                      [Page 3]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+   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 the Home Network that may forbid transit
+   traffic from Visiting Mobile Nodes in mobile networks.  In addition,
+   we will explore the impact of the MRHA tunnel on communications
+   between two Mobile Network Nodes on different links of the same
+   mobile network.  We will also provide additional motivations for
+   Route Optimization by considering the potential stalemate situation
+   when a Home Agent is part of a mobile network.
+
+2.1.  Sub-Optimality with NEMO Basic Support
+
+   With NEMO Basic Support, all packets sent between a Mobile Network
+   Node and its Correspondent Node are forwarded through the MRHA
+   tunnel, resulting in a pinball route between the two nodes.  This has
+   the following sub-optimal effects:
+
+   o  Longer Route Leading to Increased Delay and Additional
+      Infrastructure Load
+
+      Because a packet must transit from a mobile network to the Home
+      Agent then to the Correspondent Node, the transit time of the
+      packet is usually longer than if the packet were to go straight
+      from the mobile network to the Correspondent Node.  When the
+      Correspondent Node (or the mobile network) resides near the Home
+      Agent, the increase in packet delay can be very small.  However,
+      when the mobile network and the Correspondent Node are relatively
+      near to one another but far away from the Home Agent on the
+      Internet, the increase in delay is very large.  Applications such
+      as real-time multimedia streaming may not be able to tolerate such
+      increase in packet delay.  In general, the increase in delay may
+      also impact the performance of transport protocols such as TCP,
+      since the sending rate of TCP is partly determined by the round-
+      trip time (RTT) perceived by the communication peers.
+
+      Moreover, by using a longer route, the total resource utilization
+      for the traffic would be much higher than if the packets were to
+      follow a direct path between the Mobile Network Node and
+      Correspondent Node.  This would result in additional load in the
+      infrastructure.
+
+   o  Increased Packet Overhead
+
+      The encapsulation of packets in the MRHA tunnel results in
+      increased packet size due to the addition of an outer header.
+      This reduces the bandwidth efficiency, as an IPv6 header can be
+
+
+
+
+Ng, et al.                   Informational                      [Page 4]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+      quite substantial relative to the payload for applications such as
+      voice samples.  For instance, given a voice application using an 8
+      kbps algorithm (e.g., G.729) and taking a voice sample every 20 ms
+      (as in RFC 1889 [6]), the packet transmission rate will be 50
+      packets per second.  Each additional IPv6 header is an extra 320
+      bits per packet (i.e., 16 kbps), which is twice the actual
+      payload!
+
+   o  Increased Processing Delay
+
+      The encapsulation of packets in the MRHA tunnel also results in
+      increased processing delay at the points of encapsulation and
+      decapsulation.  Such increased processing may include encryption/
+      decryption, topological correctness verifications, MTU
+      computation, fragmentation, and reassembly.
+
+   o  Increased Chances of Packet Fragmentation
+
+      The augmentation in packet size due to packet encapsulation may
+      increase the chances of the packet being fragmented along the MRHA
+      tunnel.  This can occur if there is no prior path MTU discovery
+      conducted, or if the MTU discovery mechanism did not take into
+      account the encapsulation of packets.  Packet 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 susceptible to
+      link failure.  Thus, packets routed through the MRHA tunnel may be
+      subjected to a higher probability of being lost or delayed due to
+      link failure, compared to packets that traverse directly between
+      the Mobile Network Node and its Correspondent Node.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ng, et al.                   Informational                      [Page 5]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+2.2.  Bottleneck in the Home Network
+
+   Apart from the increase in packet delay and infrastructure load,
+   forwarding packets through the Home Agent may also lead to either the
+   Home Agent or the Home Link becoming a bottleneck for the aggregated
+   traffic from/to all the Mobile Network Nodes.  A congestion at home
+   would lead to additional packet delay, or even packet loss.  In
+   addition, Home Agent operations such as security check, packet
+   interception, and tunneling might not be as optimized in the Home
+   Agent software as plain packet forwarding.  This could further limit
+   the Home Agent capacity for data traffic.  Furthermore, with all
+   traffic having to pass through the Home Link, the Home Link becomes a
+   single point of failure for the mobile network.
+
+   Data packets that are delayed or discarded due to congestion at the
+   Home Network would cause additional performance degradation to
+   applications.  Signaling packets, such as Binding Update messages,
+   that are delayed or discarded due to congestion at the Home Network
+   may affect the establishment or update of bi-directional tunnels,
+   causing disruption of all traffic flow through these tunnels.
+
+   A NEMO Route Optimization mechanism that allows the Mobile Network
+   Nodes to communicate with their Correspondent Nodes via a path that
+   is different from the MRHA tunneling and thereby avoiding the Home
+   Agent may alleviate or even prevent the congestion at the Home Agent
+   or Home Link.
+
+2.3.  Amplified Sub-Optimality in Nested Mobile Networks
+
+   By allowing other mobile nodes to join a mobile network, and in
+   particular mobile routers, it is possible to form arbitrary levels of
+   nesting of mobile networks.  With such nesting, the use of NEMO Basic
+   Support further amplifies the sub-optimality of routing.  We call
+   this the amplification effect of nesting, where the undesirable
+   effects of a pinball route with NEMO Basic Support are amplified with
+   each level of nesting of mobile networks.  This is best illustrated
+   by an example shown in Figure 1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ng, et al.                   Informational                      [Page 6]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+               +--------+  +--------+  +--------+  +--------+
+               | 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 a 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ng, et al.                   Informational                      [Page 7]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+   This leads to the following problems:
+
+   o  Pinball Route
+
+      Both inbound and outbound packets will flow via the Home Agents of
+      all the Mobile Routers on their paths within the mobile network,
+      with increased latency, less resilience, and more bandwidth usage.
+      Appendix A 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] cannot be
+      applied because both the source and destination (the intermediate
+      Mobile Router and its Home Agent) are different hop to hop.
+
+   Nesting also amplifies the probability of congestion at the Home
+   Networks of the upstream Mobile Routers.  In addition, the Home Link
+   of each upstream Mobile Router will also be a single point of failure
+   for the nested Mobile Router.
+
+2.4.  Sub-Optimality with Combined Mobile IPv6 Route Optimization
+
+   When a Mobile IPv6 host joins a mobile network, it becomes a Visiting
+   Mobile Node of the mobile network.  Packets sent to and from the
+   Visiting Mobile Node will have to be routed not only via the Home
+   Agent of the Visiting Mobile Node, but also via the Home Agent of the
+   Mobile Router in the mobile network.  This suffers the same
+   amplification effect of nested mobile network mentioned in
+   Section 2.3.
+
+   In addition, although Mobile IPv6 [4] allows a mobile host to perform
+   Route Optimization with its Correspondent Node in order to avoid
+   tunneling with its Home Agent, the "optimized" route is no longer
+   optimized when the mobile host is attached to a mobile network.  This
+   is because the route between the mobile host and its Correspondent
+   Node is subjected to the sub-optimality introduced by the MRHA
+   tunnel.  Interested readers may refer to Appendix A for examples of
+   how the routes will appear with nesting of Mobile IPv6 hosts in
+   mobile networks.
+
+   The readers should also note that the same sub-optimality would apply
+   when the mobile host is outside the mobile network and its
+   Correspondent Node is in the mobile network.
+
+
+
+
+
+
+Ng, et al.                   Informational                      [Page 8]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+2.5.  Security Policy Prohibiting Traffic from Visiting Nodes
+
+   NEMO Basic Support requires all traffic from visitors to be tunneled
+   to the Mobile Router's Home Agent.  This might represent a breach in
+   the security of the Home Network (some specific attacks against the
+   Mobile Router's binding by rogue visitors have been documented in
+   [8][9]).  Administrators might thus fear that malicious packets will
+   be routed into the Home Network via the bi-directional tunnel.  As a
+   consequence, it can be expected that in many deployment scenarios,
+   policies will be put in place to prevent unauthorized Visiting Mobile
+   Nodes from attaching to the Mobile Router.
+
+   However, there are deployment scenarios where allowing unauthorized
+   Visiting Mobile Nodes is actually desirable.  For instance, when
+   Mobile Routers attach to other Mobile Routers and form a nested NEMO,
+   they depend on each other to reach the Internet.  When Mobile Routers
+   have no prior knowledge of one another (no security association,
+   Authentication, Authorization, and Accounting (AAA), Public-Key
+   Infrastructure (PKI), etc.), it could still be acceptable to forward
+   packets, provided that the packets are not tunneled back to the Home
+   Networks.
+
+   A Route Optimization mechanism that allows traffic from Mobile
+   Network Nodes to bypass the bi-directional tunnel between a Mobile
+   Router and its Home Agent would be a necessary first step towards a
+   Tit for Tat model, where MRs would benefit from a reciprocal
+   altruism, based on anonymity and innocuousness, to extend the
+   Internet infrastructure dynamically.
+
+2.6.  Instability of Communications within a Nested Mobile Network
+
+   Within a nested mobile network, two Mobile Network Nodes may
+   communicate with each other.  Let us consider the previous example
+   illustrated in Figure 1 where MNN and CN2 are sharing a communication
+   session.  With NEMO Basic Support, a packet sent from MNN to CN2 will
+   need to be forwarded to the Home Agent of each Mobile Router before
+   reaching CN2, whereas, a packet following the direct path between
+   them need not even leave the mobile network.  Readers are referred to
+   Appendix A.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
+
+
+
+
+Ng, et al.                   Informational                      [Page 9]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+      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.  Stalemate with a Home Agent Nested in a Mobile Network
+
+   Several configurations for the Home Network are described in [10].
+   In particular, there is a mobile home scenario where a (parent)
+   Mobile Router is also a Home Agent for its mobile network.  In other
+   words, the mobile network is itself an aggregation of Mobile Network
+   Prefixes assigned to (children) Mobile Routers.
+
+   A stalemate situation exists in the case where the parent Mobile
+   Router visits one of its children.  The child Mobile Router cannot
+   find its Home Agent in the Internet and thus cannot establish its
+   MRHA tunnel and forward the visitor's traffic.  The traffic from the
+   parent is thus blocked from reaching the Internet, and it will never
+   bind to its own (grandparent) Home Agent.  Appendix B gives a
+   detailed illustration of how such a situation can occur.
+
+   Then again, a Route Optimization mechanism that bypasses the nested
+   tunnel might enable the parent traffic to reach the Internet and let
+   it bind.  At that point, the child Mobile Router would be able to
+   reach its parent and bind in turn.  Additional nested Route
+   Optimization solutions might also enable the child to locate its Home
+   Agent in the nested structure and bind regardless of whether or not
+   the Internet is reachable.
+
+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 the motivation behind Route Optimization for NEMO.
+
+
+
+
+
+
+Ng, et al.                   Informational                     [Page 10]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+   We have described the sub-optimal effects of pinball routes with NEMO
+   Basic Support, how they may cause a bottleneck to be formed in the
+   Home Network, and how they get amplified with nesting of mobile
+   networks.  These effects will also be seen even when Mobile IPv6
+   Route Optimization is used over NEMO Basic Support.  In addition,
+   other issues concerning the nesting of mobile networks that might
+   provide additional motivation for a NEMO Route Optimization mechanism
+   were also explored, such as the prohibition of forwarding traffic
+   from a Visiting Mobile Node through an MRHA tunnel due to security
+   concerns, the impact of the MRHA tunnel on communications between two
+   Mobile Network Nodes on different links of the same mobile network,
+   and the possibility of a stalemate situation when Home Agents are
+   nested within a mobile network.
+
+4.  Security Considerations
+
+   This document highlights some limitations of NEMO Basic Support.  In
+   particular, some security concerns could prevent interesting
+   applications of the protocol, as detailed in Section 2.5.
+
+   Route Optimization for RFC 3963 [1] might introduce new threats, just
+   as it might alleviate existing ones.  This aspect will certainly be a
+   key criterion in the evaluation of the proposed solutions.
+
+5.  Acknowledgments
+
+   The authors wish to thank the co-authors of previous versions from
+   which this document is derived: Marco Molteni, Paik Eun-Kyoung,
+   Hiroyuki Ohnishi, Thierry Ernst, Felix Wu, and Souhwan Jung.  Early
+   work by Masafumi Watari on the extracted appendix was written while
+   still at Keio University.  In addition, sincere appreciation is also
+   extended to Jari Arkko, Carlos Bernardos, Greg Daley, T.J. Kniveton,
+   Henrik Levkowetz, Erik Nordmark, Alexandru Petrescu, Hesham Soliman,
+   Ryuji Wakikawa, and Patrick Wetterwald for their various
+   contributions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ng, et al.                   Informational                     [Page 11]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+6.  References
+
+6.1.  Normative Reference
+
+   [1]   Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
+         "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
+         January 2005.
+
+   [2]   Manner, J. and M. Kojo, "Mobility Related Terminology",
+         RFC 3753, June 2004.
+
+   [3]   Ernst, T. and H. Lach, "Network Mobility Support Terminology",
+         RFC 4885, July 2007.
+
+6.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",
+         RFC 4886, July 2007.
+
+   [6]   Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
+         "RTP: A Transport Protocol for Real-Time Applications",
+         RFC 1889, January 1996.
+
+   [7]   Deering, S. and B. Zill, "Redundant Address Deletion when
+         Encapsulating IPv6 in IPv6", Work in Progress, November 2001.
+
+   [8]   Petrescu, A., Olivereau, A., Janneteau, C., and H-Y. Lach,
+         "Threats for Basic Network Mobility Support (NEMO threats)",
+         Work in Progress, January 2004.
+
+   [9]   Jung, S., Zhao, F., Wu, S., Kim, H-G., and S-W. Sohn, "Threat
+         Analysis on NEMO Basic Operations", Work in Progress,
+         July 2004.
+
+   [10]  Thubert, P., Wakikawa, R., and V. Devarapalli, "Network
+         Mobility Home Network Models", RFC RFC4887, July 2007.
+
+   [11]  Draves, R., "Default Address Selection for Internet Protocol
+         version 6 (IPv6)", RFC 3484, February 2003.
+
+
+
+
+
+
+
+
+
+Ng, et al.                   Informational                     [Page 12]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+Appendix A.  Various Configurations Involving Nested Mobile Networks
+
+   In the following sections, we try to describe different communication
+   models that involve a nested mobile network and to clarify the issues
+   for each case.  We illustrate the path followed by packets if we
+   assume nodes only use Mobile IPv6 and NEMO Basic Support mechanisms.
+   Different cases are considered where a Correspondent Node is located
+   in the fixed infrastructure, in a distinct nested mobile network as
+   the Mobile Network Node, or in the same nested mobile network as the
+   Mobile Network Node.  Additionally, cases where Correspondent Nodes
+   and Mobile Network Nodes are either standard IPv6 nodes or Mobile
+   IPv6 nodes are considered.  As defined in [3], standard IPv6 nodes
+   are nodes with no mobility functions whatsoever, i.e., they are not
+   Mobile IPv6 or NEMO enabled.  This means that they cannot move around
+   keeping open connections and that they cannot process Binding Updates
+   sent by peers.
+
+A.1.  CN Located in the Fixed Infrastructure
+
+   The most typical configuration is the case where a Mobile Network
+   Node communicates with a Correspondent Node attached in the fixed
+   infrastructure.  Figure 3 below shows an example of such topology.
+
+                    +--------+  +--------+  +--------+
+                    | MR1_HA |  | MR2_HA |  | MR3_HA |
+                    +---+----+  +---+----+  +---+----+
+                        |           |           |
+                       +-------------------------+
+                       |        Internet         |----+ CN
+                       +-------------------------+
+                               |               |
+                           +---+---+        +--+-----+
+                 root-MR   |  MR1  |        | VMN_HA |
+                           +---+---+        +--------+
+                               |
+                           +---+---+
+                  sub-MR   |  MR2  |
+                           +---+---+
+                               |
+                           +---+---+
+                  sub-MR   |  MR3  |
+                           +---+---+
+                               |
+                           ----+----
+                              MNN
+
+                Figure 3: CN Located at the Infrastructure
+
+
+
+
+Ng, et al.                   Informational                     [Page 13]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+A.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 (HA).  As shown in Figure 4, in
+   such a 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
+
+A.1.2.  Case B: VMN and MIPv6 CN
+
+   In this second case, both end nodes are Mobile IPv6-enabled mobile
+   nodes, that is, MNN is a Visiting Mobile Node.  Mobile IPv6 Route
+   Optimization may thus be initiated between the two and packets would
+   not go through the Home Agent of the Visiting Mobile Node or 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
+
+A.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 in Figure 6:
+
+
+
+
+Ng, et al.                   Informational                     [Page 14]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+               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 an 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.
+
+A.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 in
+   Figure 7.  We define such configuration as "distinct nested mobile
+   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
+
+
+
+
+
+
+Ng, et al.                   Informational                     [Page 15]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+A.2.1.  Case D: LFN and Standard IPv6 CN
+
+   Similar to 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 of the nested mobile network,
+   decapsulated by the Home Agents, and then encapsulated again on their
+   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
+
+A.2.2.  Case E: VMN and MIPv6 CN
+
+   Similar to 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 or 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 vice 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
+
+A.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 cannot be performed because the standard IPv6
+   Correspondent Node cannot process Mobile IPv6 signaling.  MNN would
+
+
+
+Ng, et al.                   Informational                     [Page 16]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+   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 in 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 an MIPv6 Mobile Node and CN is a Standard IPv6 Node
+
+A.3.  MNN and CN 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
+
+
+
+
+Ng, et al.                   Informational                     [Page 17]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+           Figure 11: MNN and CN Located in the Same Nested NEMO
+
+A.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 of 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
+
+A.3.2.  Case H: VMN and MIPv6 CN
+
+   Similar to Case B and Case E, when both end nodes are Mobile IPv6
+   nodes, the two nodes may initiate Mobile IPv6 Route Optimization,
+   which will avoid the packets going through the Home Agent of MNN or
+   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 as 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
+
+
+
+
+
+
+Ng, et al.                   Informational                     [Page 18]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+A.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 cannot 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 in 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 an MIPv6 Mobile Node and CN is a Standard IPv6 Node
+
+A.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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ng, et al.                   Informational                     [Page 19]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+              +--------+  +--------+  +--------+  +--------+
+              | 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
+
+A.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 communications.  The path between
+   the two nodes would go through:
+
+
+                                  1
+                             MNN --- CN
+                             LFN   IPv6 Node
+
+
+               Figure 16: MNN and CN Are Standard IPv6 Nodes
+
+A.4.2.  Case K: VMN and MIPv6 CN
+
+   Similar to 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:
+
+
+
+
+Ng, et al.                   Informational                     [Page 20]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+                                  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.
+
+A.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 its Home Agent, which causes the flow to go out the
+   nested mobile network.  The 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 an MIPv6 Mobile Node and CN is a Standard IPv6 Node
+
+   However, MNN may also decide to use its Care-of Address (CoA) as the
+   source address of the packets, thus avoiding the tunneling with the
+   MNN's Home Agent.  This is particularly useful for a short-term
+   communications that may easily be retried if it fails.  Default
+   Address Selection [11] provides some mechanisms for controlling the
+   choice of the source address.
+
+
+
+
+
+
+
+
+Ng, et al.                   Informational                     [Page 21]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+Appendix B.  Example of How a Stalemate Situation Can Occur
+
+   Section 2.7 describes the occurrence of a stalemate situation where a
+   Home Agent of a Mobile Router is nested behind the Mobile Router.
+   Here, we illustrate a simple example where such a situation can
+   occur.
+
+   Consider a mobility configuration depicted in Figure 19 below.  MR1
+   is served by HA1/BR and MR2 is served by HA2.  The 'BR' designation
+   indicates that HA1 is a border router.  Both MR1 and MR2 are at home
+   in the initial step.  HA2 is placed inside the first mobile network,
+   thus representing a "mobile" Home Agent.
+
+                                                     /-----CN
+                                         +----------+
+        home link 1         +--------+   |          |
+      ----+-----------------| HA1/BR |---| Internet |
+          |                 +--------+   |          |
+          |                              +----------+
+       +--+--+  +-----+
+       | MR1 |  | HA2 |
+       +--+--+  +--+--+
+          |        |
+         -+--------+-- mobile net 1 / home link 2
+          |
+       +--+--+  +--+--+
+       | MR2 |  | LFN |
+       +--+--+  +--+--+
+           |        |
+          -+--------+- mobile net 2
+
+                       Figure 19: Initial Deployment
+
+   In Figure 19 above, communications between CN and LFN follow a direct
+   path as long as both MR1 and MR2 are positioned at home.  No
+   encapsulation intervenes.
+
+   In the next step, consider that the MR2's mobile network leaves home
+   and visits a foreign network, under Access Router (AR) like in
+   Figure 20 below.
+
+
+
+
+
+
+
+
+
+
+
+Ng, et al.                   Informational                     [Page 22]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+                                               /-----CN
+                                   +----------+
+        home link 1   +--------+   |          |
+        --+-----------| HA1/BR |---| Internet |
+          |           +--------+   |          |
+       +--+--+  +-----+            +----------+
+       | MR1 |  | HA2 |                        \
+       +--+--+  +--+--+                        +-----+
+          |        |                           | AR  |
+         -+--------+- mobile net 1             +--+--+
+                      home link 2                 |
+                                               +--+--+  +-----+
+                                               | MR2 |  | LFN |
+                                               +--+--+  +--+--+
+                                                  |        |
+                                    mobile net 2 -+--------+-
+
+                  Figure 20: Mobile Network 2 Leaves Home
+
+   Once MR2 acquires a Care-of Address under AR, the tunnel setup
+   procedure occurs between MR2 and HA2.  MR2 sends a Binding Update to
+   HA2 and HA2 replies with a Binding Acknowledgement to MR2.  The bi-
+   directional tunnel has MR2 and HA2 as tunnel endpoints.  After the
+   tunnel MR2HA2 has been set up, the path taken by a packet from CN
+   towards LFN can be summarized as:
+
+       CN->BR->MR1->HA2=>MR1=>BR=>AR=>MR2->LFN.
+
+   Non-encapsulated packets are marked "->" while encapsulated packets
+   are marked "=>".
+
+   Consider next the attachment of the first mobile network under the
+   second mobile network, like in Figure 21 below.
+
+   After this movement, MR1 acquires a Care-of Address valid in the
+   second mobile network.  Subsequently, it sends a Binding Update (BU)
+   message addressed to HA1.  This Binding Update is encapsulated by MR2
+   and sent towards HA2, which is expected to be placed in mobile net 1
+   and expected to be at home.  Once HA1/BR receives this encapsulated
+   BU, it tries to deliver to MR1.  Since MR1 is not at home, and a
+   tunnel has not yet been set up between MR1 and HA1, HA1 is not able
+   to route this packet and drops it.  Thus, the tunnel establishment
+   procedure between MR1 and HA1 is not possible, because the tunnel
+   between MR2 and HA2 had been previously torn down (when the mobile
+   net 1 moved from home).  The communications between CN and LFN stops,
+   even though both mobile networks are connected to the Internet.
+
+
+
+
+
+Ng, et al.                   Informational                     [Page 23]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+                                      /-----CN
+                          +----------+
+             +--------+   |          |
+             | HA1/BR |---| Internet |
+             +--------+   |          |
+                          +----------+
+                                      \
+                                      +-----+
+                                      | AR  |
+                                      +--+--+
+                                         |
+                                      +--+--+  +-----+
+                                      | MR2 |  | LFN |
+                                      +--+--+  +--+--+
+                                         |        |
+                           mobile net 2 -+--------+-
+                                         |
+                                      +--+--+  +-----+
+                                      | MR1 |  | HA2 |
+                                      +--+--+  +--+--+
+                                         |        |
+                           mobile net 1 -+--------+-
+
+                   Figure 21: Stalemate Situation Occurs
+
+   If both tunnels between MR1 and HA1, and between MR2 and HA2, were up
+   simultaneously, they would have "crossed over" each other.  If the
+   tunnels MR1-HA1 and MR2-HA2 were drawn in Figure 21, it could be
+   noticed that the path of the tunnel MR1-HA1 includes only one
+   endpoint of the tunnel MR2-HA2 (the MR2 endpoint).  Two MR-HA tunnels
+   are crossing over each other if the IP path between two endpoints of
+   one tunnel includes one and only one endpoint of the other tunnel
+   (assuming that both tunnels are up).  When both endpoints of one
+   tunnel are included in the path of the other tunnel, then tunnels are
+   simply encapsulating each other.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ng, et al.                   Informational                     [Page 24]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+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
+   Village d'Entreprises Green Side
+   400, Avenue de Roumanille
+   Batiment T3, 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
+   UC Davis
+   One Shields Avenue
+   Davis, CA  95616
+   US
+
+   Phone: +1 530 752 3128
+   EMail: fanzhao@ucdavis.edu
+
+
+
+
+
+
+
+
+
+
+
+
+Ng, et al.                   Informational                     [Page 25]
+
+RFC 4888               NEMO RO Problem Statement               July 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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.
+
+   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, THE IETF TRUST 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.
+
+Intellectual Property
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Ng, et al.                   Informational                     [Page 26]
+