Internet DRAFT - draft-wakikawa-manemo-problem-statement


No Working Group                                             R. Wakikawa
Internet-Draft                                           Keio University
Expires: January 10, 2008                                     P. Thubert
                                                                 T. Boot
                                                       Infinity Networks
                                                                J. Bound
                                                             B. McCarthy
                                                    Lancaster University
                                                            July 9, 2007

             Problem Statement and Requirements for MANEMO

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 10, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Wakikawa, et al.        Expires January 10, 2008                [Page 1]
Internet-Draft           PS. and Req. for MANEMO               July 2007


   The NEMO Basic Support protocol has well-known issues when multiple
   mobile routers are connected to each other in a nested fashion.
   These issues have been already analyzed in the NEMO Working Group.
   However, solutions are not yet considered and discussed in the IETF.
   MANEMO (MANET for NEMO) is an approach to resolve these issues.
   Although most of issues are relevant to what the MANET working group
   is chartered to deliver, a different approach may be required.  This
   document identifies the problems which MANEMO will solve and provides
   the MANEMO requirements.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5

   3.  MANEMO Characteristic  . . . . . . . . . . . . . . . . . . . .  6

   4.  Problem Statements . . . . . . . . . . . . . . . . . . . . . . 10

   5.  Existing Solutions and MANEMO approach . . . . . . . . . . . . 12

   6.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14

   7.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 16

   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17

   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 18

   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     10.1.  Normative reference . . . . . . . . . . . . . . . . . . . 18
     10.2.  Informative Reference . . . . . . . . . . . . . . . . . . 19

   Appendix A.  Change Log From Previous Version  . . . . . . . . . . 21

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 23

Wakikawa, et al.        Expires January 10, 2008                [Page 2]
Internet-Draft           PS. and Req. for MANEMO               July 2007

1.  Introduction

   Mobile Ad-hoc Network mechanisms have been standardized for local
   communication when wireless nodes are connected in an ad-hoc fashion.
   Several routing protocols were already standardized within the MANET
   working group and almost ready for deployment.  The AUTOCONF working
   group has been recently formed to standardize the IP address
   configuration (both local address and global address).  On the other
   hand, the NEMO working group has standardized the NEMO Basic Support
   Protocol [1] for global mobility of networks to support network
   movement transparency.  The MANET/AUTOCONF and the NEMO working
   groups discuss their solutions separately without the consideration
   of integrating them.  In the NEMO Working Group, the well-known
   issues caused by nested NEMO are addressed.  Some of them are very
   similar to what the MANET/AUTOCONF working groups deal with as a
   problem space.  However, the NEMO Basic Support protocol requires
   always connected Home Agent reachability and network movement
   transparency in relation to a mobile network.  These multiple effort
   creates some contradiction between MANET/AUTOCONF and NEMO.  We
   discuss this contradiction briefly in this document and also in [11].

   In addition to that, the MANET protocols (DYMO [12] and OLSR [13])
   may solve many of the upcoming problems introduced by new
   technologies, but implementing all functionalities of the MANET
   routing protocols may not be always desired for some specific issues.
   As the 6lowpan Working Group works on how to apply MANET protocols to
   LoWPANs (ex.  RSN mailing list: Routing Sensor Network), it may be
   required to determine the possibility of either extending or
   downsizing the existing MANET/ AUTOCONF solutions for the nested NEMO
   problems for a sensor network.  Since the nested NEMO problems are
   minor issues caused only within the NEMO Basic Support model, it may
   be time to look at a light-weight approach for the issues within the

   Solutions for MANEMO have already been proposed within the IETF such
   as [14] and [15].  The NEMO Working Group has the analysis document
   [16] for the nested NEMO issue.  MANEMO is possibly related to the
   following on- going work in IETF.

   o  Existing Routing Protocols (MANET, OSPF)

   o  Network Mobility Support (NEMO)

   o  Mobile Ad-hoc Network and Auto Configuration (AUTOCONF)

   o  Mobile Ad-hoc Sensor Network (6LOWPAN)

Wakikawa, et al.        Expires January 10, 2008                [Page 3]
Internet-Draft           PS. and Req. for MANEMO               July 2007

   o  Mobile Nodes and Multiple Interfaces in IPv6 (Monami6)

Wakikawa, et al.        Expires January 10, 2008                [Page 4]
Internet-Draft           PS. and Req. for MANEMO               July 2007

2.  Terminology

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [2]

   Readers are expected to be familiar with all the terms defined in the
   RFC3753 [3] and the NEMO Terminology draft [4]

   MANEMO Fringe Stub (MFS)  The MANEMO Fringe Stub is a cloud of Mobile
      Routers connected by wireless or wired links.  Any type of link
      supporting IPv6 connectivity can be used, including partly meshed
      wireless topologies.  An MFS is a stub at the edge of the
      Internet, interconnecting various types of devices which discover
      each other and form a network in an ad-hoc fashion to provide
      global connectivity to one another.  Many disjunctive MFS can be
      connected to the Internet.  An MFS can also be floating, which
      means the cloud is not connected to the Internet.

   Exit Router  The Exit Router is a router which provides connectivity
      to the Internet and acts as a layer-3 sink for the MFS.  The Exit
      Router can be a fixed Access Router supporting MANEMO or a mobile
      router (root-MR) connected directly to the Internet.  Multiple
      Exit Routers may be available in an MFS.

   MANEMO  MANET for NEMO.  MANEMO provides the necessary additions to
      existing protocols (IPv6, ND, NEMO), for nested Mobile Routers to
      find the most suited exit towards the Internet.  MANEMO enables
      some internal connectivity within the nested NEMO whether the
      Internet is reachable or not.  MANEMO is not MANET + NEMO.  MANET
      + NEMO could suggest a MANET protocol reuse whereas MANET for NEMO
      suggests the development of a new protocol.

   Nested NEMO  The Nested NEMO is a network configuration where one or
      more mobile routers are connected in a nested formation.  The
      detailed issues can be found in [17] and [18].

Wakikawa, et al.        Expires January 10, 2008                [Page 5]
Internet-Draft           PS. and Req. for MANEMO               July 2007

3.  MANEMO Characteristic

   Before discussing the detail of MANEMO problems, we highlight the
   characteristics of MANEMO Fringe Stub (MFS) by comparing it with a
   traditional ad-hoc network (MANET) in this section.

   Mobile routers of RFC3963 are the core nodes of an MFS.  A mobile
   network served by a mobile router is seen as a normal IPv6 network.
   It is possible for a mobile router to connect to another mobile
   router's mobile network.  As a result, mobile routers are connected
   and form a nested topology which is known as nested NEMO.  In MFS,
   not only mobile routers, but also mobile hosts, fixed nodes (host and
   router) are considered.  Fixed hosts and routers can be connected to
   one of the mobile networks and can also be located in the Internet.
   Access routers to provide wireless connectivity are also considered
   as a node within an MFS.  All these nodes may be involved within the
   MANEMO protocol.  Figure 1 shows the abstract topology of mobile
   routers.  Two exit routers (ER1 and ER2) are identified and each
   number indicates a mobile router.  In order to highlight the MANEMO
   characteristic, we only show the mobile routers in the topology.  We
   discuss all the possible topologies of mobile routers in MFS in the
   MANEMO architecture [11].  Each mobile router owns an assigned prefix
   from its home agent.  The prefix is configured for a mobile network.
   A mobile router acquires a topologically correct address (care-of
   address) at the egress interface and tunnels all the data to its home
   agent by using the care-of address.

   Although MANET supports Internet connectivity, because of NEMO Basic
   Support, the reachability to its home agent for home registration is
   a fundamental aspect of MANEMO.  Without home registration, it cannot
   communicate to other nodes with its mobile network prefix according
   to RFC3963.  If the binding registration is completed, all the
   traffic from the mobile network is tunneled to the home agent.  In
   NEMO context, at least one exit router for MFS is required.  MR1 and
   MR3 of Figure 1 can be away from the wireless attach facility and
   loose connectivity to the network.  The disconnected MFS can also
   occur.  Moreover, on the MANEMO mailing list, we currently discuss
   the case when each mobile router is connected by the egress interface
   and forms a MANET-like network.  This case can be seen as "mobile
   routers forming a mobile ad-hoc network".  Except for the assigned
   prefix to each mobile router, the characteristic of this scenario may
   be same as mobile ad-hoc network.

Wakikawa, et al.        Expires January 10, 2008                [Page 6]
Internet-Draft           PS. and Req. for MANEMO               July 2007

        +-------------------+         Internet (Wired/Wireless)
        |                   |            |
        |                   |           \|/
       ER1                 ER2          /|\
        |                  /             |
        1---2             3              |
        |\               /               | Wireless Links
        4  5---6---7----8--9             |
        |       \        \               |
        10---11  12       13---14       \|/

                        Figure 1: Example Topology

   Figure 2 shows the difference of communication model between MANET
   and MANEMO.  A mobile router (MR6) communicates with another mobile
   router (MR14) .  The Figure 2-a shows the basic MANET communication
   model.  MANET protocols maintain local routing information so that
   they can communicate directly inside this ad-hoc network.  Even if
   there are multi-paths between nodes, most of the MANET routing
   protocols select the shortest path in default.  If many sessions are
   in process within the network, the congestion at some links can be
   obviously observed.  The links between MR6 to MR8 in Figure 2 may
   become possible bottlenecks if many nodes are communicating at the
   same time.  Figure 2-b, on the other hand, shows the MANEMO
   communication model.  The default communication path between MR6 and
   MR14 is through the Internet.  Each mobile router transmits packets
   to the exit router even if the destination node is located nearby.
   Thus, packets are traveled over the Internet (through several home
   agents if it is required) and routed to the exit router to which the
   destination mobile router belongs.  Even if the path length may
   increase, the path over the Internet is often more reliable than the
   shortest link.  Note that it is true that the link between ER1-MR1
   and ER2-MR3 become the bottleneck for all the traffic coming in and
   out of the MFS.  Additional latency may also be observed, but it is a
   trade-off of several aspects such as latency, congestion, reliability
   and costs of local routing management (MANET routing protocol).  In
   MANEMO, it is still possible to maintain the neighboring mobile
   routers.  End nodes can communicate to the destination directly along
   the shortest path (not through the exit routers).  Each mobile router
   should be able to decide whether the packets are routed to the exit
   router or to the destination directly.  MANEMO does not identify how
   to manage local routing, but the primarily goal is to manage the path
   to the exit router as a default.

Wakikawa, et al.        Expires January 10, 2008                [Page 7]
Internet-Draft           PS. and Req. for MANEMO               July 2007

                                        +===== HAn  =======+
                                       ER1                ER2
                                       ||                //
        1---2            3             1---2            3
        |\               /             |\\              //
        4  5---6<==7====8--9           4  5==>6---7----8--9
        |       \        \\            |       \        \\
        10---11  12       13==>14      10---11  12       13==>14

             a) MANET                          b) MANEMO

                       Figure 2: Communication Model

   When a mobile router changes its point of attachment, it must hide
   the changes from any nodes located in its mobile network [1].  Since
   nodes in the mobile network are moved all together, sets of mobile
   routers can move at once in MFS.  Nodes can be an IPv6 node, a mobile
   host of RFC3775, and a mobile router of RFC3963.  For instance, in
   Figure 3, a mobile router (MR4) moves its point of attachment.  Even
   if MR4 moves, the movement has minimum impact to any nodes including
   mobile routers (MR10 and MR11) located in the MR4's mobile network.
   The mobile network nodes must be completely unaware of the movement.
   On the other hand, within most of the MANET and AUTOCONF schemes, the
   change of MR4's attachment effects the neighboring nodes (possibly
   the entire network).  Most of the routing protocols require the route
   re-calculation or route re-discovery (route maintenance) when
   topology changes are occurred.  This should be avoided because it
   breaks the nature of the NEMO basic support protocol.  A detailed
   explanation can be found in [11].

        +------------------+          +------------------+
       ER1                ER2        ER1                ER2
        |                 /           |                 /
        1---2            3      ==>   1---2            3
        |\               /             \               /
       |4| 5---6---7----8--9             5---6---7----8--9
        |       \        \                    \        \
        10---11  12       13---14              12       13---14
      Router-4 moves to Router-12             |4|
                                              > 10---11

Wakikawa, et al.        Expires January 10, 2008                [Page 8]
Internet-Draft           PS. and Req. for MANEMO               July 2007

                                      movement transparency

                         Figure 3: Movement Model

   Another aspect of MANEMO characteristic is that each mobile router
   can be connected by different wireless technology, while a default
   MANET assumption is to use a single wireless interface in ad-hoc mode
   (ex. 802.11b ad-hoc mode).  Each mobile router has, at least two
   interfaces such as egress and ingress interfaces.  For example, MR3
   connects to ER2 by 3G (HSDPA), MR3 and MR8 are connected by 802.11b,
   MR8 and MR13 are by 802.11g, and so on. as described in Figure 4.

       ER1                ER2
        | WiMAX           / <-3G(HSDPA)
        1---2            3
        |\               / <-wifi(802.11b)
        4 5---6---7----8--9
        |       \        \ <-wifi(802.11g)
        10---11  12       13---14

                         Figure 4: Movement Model

   The final difference is the routing capability.  In MANET, each
   router can route the packet received at the manet interface [19].  A
   route can receive a packet from a manet interface and can send the
   packet from the same manet interface according to its routing table.
   However, in the NEMO Basic Support model, a mobile router can route
   only the tunneled packet to and from its mobile network.  Without the
   bi- directional tunnel, the mobile router never routes the non-
   tunneled packet according to [1].  The packet sent from the ingress
   interface is always routed to the mobile router's home agent by using
   IP encapsulation.  The incoming packets must always be tunneled from
   the mobile router's home agent except for the packets sent to the
   mobile node itself.

Wakikawa, et al.        Expires January 10, 2008                [Page 9]
Internet-Draft           PS. and Req. for MANEMO               July 2007

4.  Problem Statements

   Radio connectivity and movement have disrupted the concept of a link
   as we know it in the wired environment.  Specific modes for specific
   radios are proposed to restore that concept, which is essential for
   IP operations, as single hop (802.11 infrastructure mode) or multihop
   (802.11S, 802.15.5, 802.16J).  MANEMO aims a proposing a unified
   solution to reconstruct a minimum topological abstraction at layer 3
   for the use of NEMO.

   The MANEMO problems are already observed in several Working Groups
   and some are specified in [17], [20]

   1.  Sub-optimal route and Redundant tunnel: This issue is described
       in Section 2.1, 2.3 and 2.6 of [17] and in Appendix B.1, B.2,
       B.3, B.4 of [17].

   2.  No Communication capability without Home Agent Reachability: This
       issue is described in Section 2.6 of [17]

   3.  Exit Router Selection: This problem occurs when a mobile node
       obtains multiple Exit Routers toward the Internet.  In the
       illustrated case, the mobile node should attempt to obtain some
       information about each Exit Router in order to more efficiently
       utilize them.  MANEMO may carry this information about each Exit
       Router and present it to the connected mobile node.

               . . . . . . . . . . . ..
               .                      .
               .     The Internet     .
               .                      .
               .. . . . . . . . . . . .
                  |             |
                +-+-+         +-+-+
                |AR1|         |AR2+--+
                +-+-+         +-+-+  |
                  |     +---+    |   |
                  +-----|MR1|----+   |
                        +-+-+        |
                          |        +-+-+

                        Figure 5: Multiple Exit Routers

Wakikawa, et al.        Expires January 10, 2008               [Page 10]
Internet-Draft           PS. and Req. for MANEMO               July 2007

   4.  Network Loop: A network loop can occur when multiple mobile
       routers are nested and suddenly the Exit Router (root-MR, i.e.
       MR1) looses connectivity to the Internet and connects to the
       mobile network of a lower hierarchical MR (i.e.  MR2 in the
       figure).  In this case, the loop is observed between mobile
       routers.  Each mobile network is designed to have movement
       transparency from the NEMO Basic Support Protocol.  Any node
       connecting to a mobile network cannot know whether the access
       network is a mobile network or not.  Moreover, it is impossible
       to know whether a connecting mobile router has managed Internet
       connectivity or not.  The mobile router may loose Internet
       Connectivity, temporarily.

               Internet            Internet
                  |                   |
                +-+-+               +-+-+
                |AR |               |AR |
                +-+-+               +---+
                +-+-+               +---+
                |MR1|     -->       |MR1+->+
                +-+-+               +-+-+  |
                  |                  /|\   |
                  |                   |    |
                +-+-+               +-+-+ \|/
                |MR2|               |MR2|<-+
                +---+               +---+

                            Figure 6: Network Loop

       Section 4.8 of [20] discussed the loop problem when a mobile
       router is multihomed.

Wakikawa, et al.        Expires January 10, 2008               [Page 11]
Internet-Draft           PS. and Req. for MANEMO               July 2007

5.  Existing Solutions and MANEMO approach

   Several approaches can be taken for the problems listed in Section 4.
   Some analysis can be found in [21].

   [MANET Routing Protocol and AUTOCONF]  While manet routing protocols
      maintain the local connectivity, the primary goal of MANEMO is to
      discover an exit router and to maintain the path to the Internet
      through the exit router for binding registration and traffic over
      the bidirectional tunnel.  Only for this purpose, MANET routing
      protocols have excess functionalities such as flooding messages
      for route discovery or route updates, etc.  The primary goal of
      the MANET routing protocols is to maintain local connectivity.
      However, the local connectivity management should not be mandated
      to the MANEMO solution, although MANEMO may be interested in the
      local routing in the future.  The NEMO Basic Support protocol
      basically requires tunneling the packets to the Internet.  NHDP
      [22] is alternate solution to discover neighboring nodes, but it
      is limited to only two hop neighbors' information.  There is a
      case that an exit router is more than 2 hops away.  The AUTOCONF
      working group discusses the address assignment scheme for ad-hoc
      networks.  However, the addressing architecture is slightly
      different from what the NEMO basic support protocol is expecting.
      More details can be found in [11].

   [NEMO Route Optimization Scheme]  There is no route optimization
      scheme in IETF.  Only the analysis document is available in [16].

   Contrary to the existing solutions, MANEMO arranges a tree structure
   towards the Internet.  This tree is the simplest network topology
   connecting Mobile Routers within an MFS to a single Exit Router.  The
   Exit Router is the root of the MANEMO Tree.  The packets from MFS are
   routed along the tree and are routed to the destination.  Routing to
   multiple home agents should be avoided as much as possible.  Basic
   required functionalities for MANEMO are:

   1.  Discovering and Selecting exit routers

   2.  Forming loop-free Tree by making an exit router as a root

   3.  Maintaining the path to the exit router

   4.  Bypassing Home Agents for the traffic from MFS

   The MANEMO work focus is on a Neighbor Discovery (ND) [5] based
   solution that is required to provide multihop reachability while
   supporting the inner movements within the nested NEMO.  ND provides
   the means to discover neighbors and the prefix on a link, which are

Wakikawa, et al.        Expires January 10, 2008               [Page 12]
Internet-Draft           PS. and Req. for MANEMO               July 2007

   pervasive across IPv6 nodes and link types.  Mobile IPv6 [6] and NEMO
   [1] rely heavily on ND for roaming and Home Link activities.
   Considering that NEMO already uses ND for Router Discovery, it makes
   sense to extend ND in MANEMO as opposed to providing a second peering

   ND has already been extended to expose some layer 3 information, such
   as router selection hints [7].  ND is consistently being improved for
   mobility, in particular with Mobile IPv6 [6] and DNA [23], and for
   security with Secure ND [8].  ND operates on bidirectional links,
   whereas this is a restriction from the MANET standpoint, this
   condition enables simpler solutions for MANEMO.  Neighbor Discovery
   is well suited for providing hints for composing a path to the
   Internet access router.  The Exit Routes connect MFS to the Internet.

   Multicast support could be provided by using the loop-free MANEMO
   Tree to forward packets to the Internet.  Down-tree forwarding would
   use MLD-proxy [24], either with native MLD [9][10] / ICMP packets or
   send with the ND extensions to increase efficiency.

Wakikawa, et al.        Expires January 10, 2008               [Page 13]
Internet-Draft           PS. and Req. for MANEMO               July 2007

6.  Requirements

   MANEMO has the following requirements:

   R1:  MANEMO must enable the discovery of multihop topologies at layer
      3 from mere reachability and elaborate links for IPv6 usage,
      regardless of the wired or wireless media.

   R2:  MANEMO must enable packets transmitted from nodes visiting the
      MFS to reach the Internet via an optimized path towards the
      nearest Exit Router, and back.

   R3:  MANEMO must enable IP connectivity within the MFS whether
      Internet is reachable or not.

   R4:  MANEMO must enable packets transmitted from nodes visiting the
      MFS to reach the Internet with a topologically correct address.

   R5:  MANEMO should aim at minimizing radio interference with itself
      as the control messages get propagated in the MFS.

   R6:  MANEMO must enable inner movements within MFS to occur, and
      ensure propagating details of this movement is kept at a minimum.

   R7:  An MFS may split to become two separate MFSs, in this case
      MANEMO must continue to maintain local connectivity within the
      separate MFSs and connectivity between the split MFSs.  MFSs may
      merge, in this case inner MFS connectivity optimization must be

   R8:  MANEMO should enable and optimize the trade-off between ensuring
      some reciprocity between MFS peers and maintaining a safe degree
      of CIA properties between the peer Mobile Routers.

   R9:  MANEMO must support ad-hoc operation, for isolated MFSs (R3) and
      multi-hop access to the Internet (R2).

   R10:  MANEMO must not require modifications to any node other than
      nodes that participates to the MFS, including HA.  It must support
      fixed nodes, mobile hosts and mobile routers in the MFS, and
      ensure backward compatibility with other standards defined by the

   R11:  MANEMO should enable multicast communication, for nodes within
      the MFS and on the Internet.

Wakikawa, et al.        Expires January 10, 2008               [Page 14]
Internet-Draft           PS. and Req. for MANEMO               July 2007

   R12:  MANEMO must optimize the path to the Internet using cross-layer

   R13:  MANEMO may provide direct peer to peer reachability for nearby

Wakikawa, et al.        Expires January 10, 2008               [Page 15]
Internet-Draft           PS. and Req. for MANEMO               July 2007

7.  IANA considerations

   This document does not require any IANA action.

Wakikawa, et al.        Expires January 10, 2008               [Page 16]
Internet-Draft           PS. and Req. for MANEMO               July 2007

8.  Security Considerations

   This document is a problem statement and does not create any security
   threat.  It discusses the concepts of Capability, Innocuousness and
   Anonymity in a nested NEMO.

Wakikawa, et al.        Expires January 10, 2008               [Page 17]
Internet-Draft           PS. and Req. for MANEMO               July 2007

9.  Acknowledgments

   We would like to thank all the people who have provided comments on
   this draft, and also co-authors of earlier documents in which authors
   of this present document have been engaged.  As such, we would like
   to thank Niko A. Fikouras, Yoshihiro Ohba, Emmanuel Baccelli, Hesham
   Soliman, Carlos Jesus Bernardos Cano and many others.

10.  References

10.1.  Normative reference

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

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

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

   [4]   Ernst, T. and H. Lach, "Network Mobility Support Terminology",
         draft-ietf-nemo-terminology-06 (work in progress),
         November 2006.

   [5]   Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
         for IP Version 6 (IPv6)", RFC 2461, December 1998.

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

   [7]   Draves, R. and D. Thaler, "Default Router Preferences and More-
         Specific Routes", RFC 4191, November 2005.

   [8]   Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
         Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [9]   Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
         Discovery (MLD) for IPv6", RFC 2710, October 1999.

   [10]  Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
         (MLDv2) for IPv6", RFC 3810, June 2004.

Wakikawa, et al.        Expires January 10, 2008               [Page 18]
Internet-Draft           PS. and Req. for MANEMO               July 2007

10.2.  Informative Reference

   [11]  Wakikawa, R., "MANEMO Topology and Addressing Architecture",
         draft-wakikawa-manemoarch-00 (work in progress), July 2007.

   [12]  Perkins, C. and I. Chakeres, "Dynamic MANET On-demand (DYMO)
         Routing", draft-ietf-manet-dymo-10 (work in progress),
         July 2007.

   [13]  Clausen, T., "The Optimized Link State Routing Protocol version
         2", draft-ietf-manet-olsrv2-03 (work in progress), March 2007.

   [14]  Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and
         its application to Mobile Networks",
         draft-thubert-nemo-reverse-routing-header-07 (work in
         progress), February 2007.

   [15]  Thubert, P., "Nested Nemo Tree Discovery",
         draft-thubert-tree-discovery-06 (work in progress), July 2007.

   [16]  Ng, C., "Network Mobility Route Optimization Solution Space
         Analysis", draft-ietf-nemo-ro-space-analysis-03 (work in
         progress), September 2006.

   [17]  Ng, C., "Network Mobility Route Optimization Problem
         Statement", draft-ietf-nemo-ro-problem-statement-03 (work in
         progress), September 2006.

   [18]  Clausen, T., "NEMO Route Optimisation Problem Statement",
         draft-clausen-nemo-ro-problem-statement-01 (work in progress),
         March 2007.

   [19]  Chakeres, I., "Mobile Ad hoc Network Architecture",
         draft-chakeres-manet-arch-01 (work in progress), October 2006.

   [20]  Ng, C., "Analysis of Multihoming in Network Mobility Support",
         draft-ietf-nemo-multihoming-issues-07 (work in progress),
         February 2007.

   [21]  Boot, T., "Analysis of MANET and NEMO",
         draft-boot-manet-nemo-analysis-01 (work in progress),
         June 2007.

   [22]  Clausen, T., "MANET Neighborhood Discovery Protocol (NHDP)",
         draft-ietf-manet-nhdp-04 (work in progress), July 2007.

   [23]  Kempf, J., "Detecting Network Attachment in IPv6 Networks
         (DNAv6)", draft-ietf-dna-protocol-06 (work in progress),

Wakikawa, et al.        Expires January 10, 2008               [Page 19]
Internet-Draft           PS. and Req. for MANEMO               July 2007

         June 2007.

   [24]  Janneteau, C., "IPv6 Multicast for Mobile Networks with MLD-
         Proxy", draft-janneteau-nemo-multicast-mldproxy-00 (work in
         progress), April 2004.

Wakikawa, et al.        Expires January 10, 2008               [Page 20]
Internet-Draft           PS. and Req. for MANEMO               July 2007

Appendix A.  Change Log From Previous Version

   o  Removed Use-Case Scenarios

   o  Updated the Section4: use the references to existing documents

   o  Removed the Approach Rationale

Authors' Addresses

   Ryuji Wakikawa
   Department of Environmental Information, Keio University
   5322 Endo
   Fujisawa, Kanagawa

   Phone: +81-466-49-1100
   Fax:   +81-466-49-1395

   Pascal Thubert
   Cisco Systems
   Village d'Entreprises Green Side
   400, Avenue de Roumanille
   Batiment T3
   Biot - Sophia Antipolis  06410

   Phone: +33 4 97 23 26 34

   Teco Boot
   Infinity Networks B.V.
   Elperstraat 4
   Schoonloo  9443TL


Wakikawa, et al.        Expires January 10, 2008               [Page 21]
Internet-Draft           PS. and Req. for MANEMO               July 2007

   Jim Bound
   PO BOX 570
   Hollis, NH  03049

   Phone: +603 465 3130

   McCarthy Ben
   Lancaster University
   Computing Department, Lancaster University.
   InfoLab 21, South Drive
   Lancaster, Lancashire  LA1 4WA

   Phone: +44-1524-510-383
   Fax:   +44-1524-510-492

Wakikawa, et al.        Expires January 10, 2008               [Page 22]
Internet-Draft           PS. and Req. for MANEMO               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

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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Wakikawa, et al.        Expires January 10, 2008               [Page 23]