[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-janneteau-nemo-requirements) 00 01 02 03 04 05 06 RFC 4886

NEMO Working Group                                              T. Ernst
Internet-Draft                                                     INRIA
Intended status: Informational                          November 8, 2006
Expires: May 12, 2007

            Network Mobility Support Goals and Requirements

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 May 12, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Ernst                     Expires May 12, 2007                  [Page 1]

Internet-Draft                 NEMO Goals                  November 2006


   Network mobility arises when a router connecting a network to the
   Internet dynamically changes its point of attachment to the Internet
   thereby causing the reachability of the said network to be changed in
   relation to the fixed Internet topology.  Such kind of network is
   referred to as a mobile network.  With appropriate mechanisms,
   sessions established between nodes in the mobile network and the
   global Internet can be maintained after the mobile router changes its
   point of attachment.  This document outlines the goals expected from
   network mobility support and defines the requirements that must be
   met by the NEMO Basic Support solution.

Table of Contents

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

   2.  NEMO Working Group Objectives and Methodology  . . . . . . . .  5

   3.  NEMO Support Design Goals  . . . . . . . . . . . . . . . . . .  7
     3.1.  Migration Transparency . . . . . . . . . . . . . . . . . .  7
     3.2.  Performance Transparency and Seamless Mobility . . . . . .  7
     3.3.  Network Mobility Support Transparency  . . . . . . . . . .  7
     3.4.  Operational Transparency . . . . . . . . . . . . . . . . .  7
     3.5.  Arbitrary Configurations . . . . . . . . . . . . . . . . .  7
     3.6.  Local Mobility and Global Mobility . . . . . . . . . . . .  8
     3.7.  Scalability  . . . . . . . . . . . . . . . . . . . . . . .  9
     3.8.  Backward Compatibility . . . . . . . . . . . . . . . . . .  9
     3.9.  Secure Signaling . . . . . . . . . . . . . . . . . . . . .  9
     3.10. Location Privacy . . . . . . . . . . . . . . . . . . . . . 10
     3.11. IPv4 and NAT Traversal . . . . . . . . . . . . . . . . . . 10

   4.  NEMO Basic Support One-Liner Requirements  . . . . . . . . . . 11

   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13

   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14

   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15

   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 16

   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18

Ernst                     Expires May 12, 2007                  [Page 2]

Internet-Draft                 NEMO Goals                  November 2006

1.  Introduction

   Network mobility support (see [1] for the related terminology) is
   concerned with managing the mobility of an entire network, viewed as
   a single unit, which changes its point of attachment to the Internet
   and thus its reachability in the Internet topology.  Such a network
   is referred to as a mobile network and includes one or more mobile
   routers (MRs) which connect it to the global Internet.  Nodes behind
   the MR(s) (MNNs) are both fixed (LFNs) and mobile (VMNs or LMNs).  In
   most cases, the internal structure of the mobile network will be
   relatively stable (no dynamic change of the topology), but this is
   not always true.

   Cases of mobile networks include, for instance:

   o  Networks attached to people (Personal Area Networks or PANs): a
      cell-phone with one cellular interface and one Bluetooth interface
      together with a Bluetooth-enabled PDA constitute a very simple
      instance of a mobile network.  The cell-phone is the mobile router
      while the PDA is used for web browsing or runs a personal web

   o  Networks of sensors and computers deployed in vehicles: vehicles
      are increasingly embedded with a number of processing units for
      safety and ease of driving reasons, as advocated by ITS
      (Intelligent Transportation Systems) applications ([4]).

   o  Access networks deployed in public transportation (buses, trains,
      taxis, aircrafts): they provide Internet access to IP devices
      carried by passengers: laptop, camera, mobile phone: host mobility
      within network mobility or PANs: network mobility within network
      mobility, i.e. nested mobility (see [1] for the definition of
      nested mobility).

   o  Ad-hoc networks connected to the Internet via an MR: for instance
      students in a train that need both to set up an ad-hoc network
      among themselves, and get Internet connectivity through the MR
      connecting the train to the Internet.

   Mobility of networks does not cause MNNs to change their own physical
   point of attachment; however they do change their topological
   location with respect to the global Internet.  If network mobility is
   not explicitly supported by some mechanisms, the mobility of the MR
   results in MNNs losing Internet access and breaking ongoing sessions
   between arbitrary correspondent node (CNs) in the global Internet and
   those MNNs located within the mobile network.  In addition, the
   communication path between MNNs and correspondent nodes becomes sub-
   optimal, and multiple levels of mobility will cause extremely sub-

Ernst                     Expires May 12, 2007                  [Page 3]

Internet-Draft                 NEMO Goals                  November 2006

   optimal routing.

   Mobility-related terms used in this document are defined in [2],
   whereas terms specifically pertaining to network mobility are defined
   in [1].  This document is structured as follows: in Section 2 we
   define the rough objectives and methodology of the NEMO working group
   to handle network mobility issues and we emphasize the stepwise
   approach the working group has decided to follow.  A number of
   desirable design goals are listed in Section 3.  Those design goals
   then serve as guidelines to define the requirements listed in
   Section 4 for basic network mobility support [3].

Ernst                     Expires May 12, 2007                  [Page 4]

Internet-Draft                 NEMO Goals                  November 2006

2.  NEMO Working Group Objectives and Methodology

   The mechanisms required for handling network mobility issues were
   lacking within the IETF standards when the NEMO working group was set
   up at the IETF in 2002.  At that time, work conducted on mobility
   support (particularly in the Mobile IP working group) was to provide
   continuous Internet connectivity and optimal routing to mobile hosts
   only (host mobility support).  Such mechanisms speficied in Mobile
   IPv6 [5] are unable to support network mobility.  The NEMO working
   group has therefore been set up to deal with issues specific to
   network mobility.

   The primary objective of the NEMO work is to specify a solution which
   allows mobile network nodes (MNNs) to remain connected to the
   Internet and continuously reachable at all times while the mobile
   router seving the mobile network changes its point of attachment.
   The secondary goals of the work is to investigate the effects of
   network mobility on various aspects of internet communication such as
   routing protocol changes, implications of real-time traffic and fast
   handovers, and optimizations.  This should support the primary goal
   of reachability for mobile network nodes.  Security is an important
   consideration too, and efforts should be made to use existing
   security solutions if they are appropriate.  Although a well-designed
   solution may include security inherent in other protocols, mobile
   networks also introduce new challenges.

   To complete these tasks, the NEMO working group has decided to take a
   stepwise approach.  The steps in this approach include standardizing
   a basic solution to preserve session continuity (NEMO Basic Support,
   see [3]), and studying the possible approaches and issues with
   providing more optimal routing with potentially nested mobile
   networks (NEMO Extended Support, see [6] and [7] for a discussion on
   routing optimization issues and [8] multihoming issues).  However,
   the working group is not chartered to actually standardize a solution
   for extgended support at this point in time.  If deemed necessary,
   the working group will be rechartered based on the conclusions of the

   For NEMO Basic Support, the working group assumes that none of the
   nodes behind the MR is aware of the network's mobility; thus, the
   network's movement needs to be completely transparent to the nodes
   inside the mobile network.  This assumption accommodates nodes inside
   the network that are not generally aware of mobility.

   The efforts of the Mobile IP working group have resulted in the
   Mobile IPv4 and Mobile IPv6 protocols, which have already solved the
   issue of host mobility support.  Since challenges to enabling mobile
   networks are vastly reduced by this work, basic network mobility

Ernst                     Expires May 12, 2007                  [Page 5]

Internet-Draft                 NEMO Goals                  November 2006

   support has adopted the methods for host mobility support used in
   Mobile IP, and has extended them in the simplest way possible to
   achieve its goals.  The basic support solution, now defined in [3]
   following the requirements stated in Section 4 of the present
   document, is for each MR to have a Home Agent, and use bi-directional
   tunneling between the MR and HA to preserve session continuity while
   the MR moves.  The MR acquires a Care-of address (CoA) at its
   attachment point much like what is done for mobile hosts (MH), using
   Mobile IP.  This approach allows nested mobile networks, since each
   MR will appear to its attachment point as a single node.

Ernst                     Expires May 12, 2007                  [Page 6]

Internet-Draft                 NEMO Goals                  November 2006

3.  NEMO Support Design Goals

   This section details the fundamental design goals the solutions will
   intend to achieve.  Those design goals serve to define the issues and
   to impose a list of requirements for forthcoming solutions.  Actual
   requirements for NEMO Basic Support are in Section 4; NEMO Extended
   Support is not yet considered at the time of this writing.

3.1.  Migration Transparency

   Permanent connectivity to the Internet has to be provided to all
   MNNs, since continuous sessions are expected to be maintained as the
   mobile router changes its point of attachment.  For maintaining those
   sessions, MNNs are expected to be reachable via their permanent IP

3.2.  Performance Transparency and Seamless Mobility

   NEMO support is expected to be provided with limited signaling
   overhead and to minimize the impact of handovers on applications, in
   terms of packet loss or delay.  However, although variable delays of
   transmission and losses between MNNs and their respective CNs could
   be perceived as the network is displaced, it would not be considered
   a lack of performance transparency.

3.3.  Network Mobility Support Transparency

   MNNs behind the MR(s) do not change their own physical point of
   attachment as a result of the mobile network's displacement in the
   Internet topology.  Consequently, NEMO support is expected to be
   performed only by the MR(s).  Specific support functions on any other
   node than the MR(s) would better be avoided.

3.4.  Operational Transparency

   NEMO support is to be implemented at the level of IP layer.  It is
   expected to be transparent to upper layers so that any upper layer
   protocol can run unchanged on top of an IP layer extended with NEMO

3.5.  Arbitrary Configurations

   The formation of a mobile network can occur in various levels of
   complexity.  In the simplest case, a mobile network contains just a
   mobile router and a host.  In the most complicated case, a mobile
   network is multihomed and is itself a multi-level aggregation of
   mobile networks with collectively thousands of mobile routers and
   hosts.  While the list of potential configurations of mobile networks

Ernst                     Expires May 12, 2007                  [Page 7]

Internet-Draft                 NEMO Goals                  November 2006

   cannot be limited, at least the following ones are desirable:

   o  Mobile networks of any size, ranging from a sole subnet with a few
      IP devices to a collection of subnets with a large number of IP

   o  Nodes that change their point of attachment within the mobile

   o  Foreign mobile nodes that attach to the mobile network.

   o  Multihomed mobile network: either when a single MR has multiple
      attachments to the internet, or when the mobile network is
      attached to the Internet by means of multiple MRs (see definition
      in [1] and the analysis in [8]).

   o  Nested mobile networks (mobile networks attaching to other mobile
      networks (see definition in [1]).  Although the complexity
      requirements of those nested networks is not clear, it is
      desirable to support arbitrary levels of recursive networks.  The
      solution should only impose restrictions on nesting (e.g. path
      MTU) when this is impractical and protocol concerns preclude such

   o  Distinct mobility frequencies (see mobility factor in [2]).

   o  Distinct access media.

   In order to keep complexity minimal, transit networks are excluded
   from this list.  A transit network is one in which data would be
   forwarded between two endpoints outside of the network, so that the
   network itself simply serves as a transitional conduit for packet
   forwarding.  A stub network (leaf network), on the other hand, does
   not serve as a data forwarding path.  Data on a stub network is
   either sent by or addressed to a node located within that network.

3.6.  Local Mobility and Global Mobility

   Mobile networks and mobile nodes owned by different administrative
   entities are expected to be displaced within a domain boundary or
   between domain boundaries.  Multihoming, vertical and horizontal
   handoffs, and access control mechanisms are desirable to achieve this
   goal.  Such mobility is not expected to be limited for any
   consideration other than administrative and security policies.

Ernst                     Expires May 12, 2007                  [Page 8]

Internet-Draft                 NEMO Goals                  November 2006

3.7.  Scalability

   NEMO support signaling and processing is expected to scale to a
   potentially large number of mobile networks irrespective of their
   configuration, mobility frequency, size and number of CNs.

3.8.  Backward Compatibility

   NEMO support will have to co-exist with established IPv6 standards
   and not interfer with them.  Standards defined in other IETF working
   groups have to be reused as much as possible and extended only if
   deemed necessary.  For instance, the following mechanisms defined by
   other working groups are expected to function without modidication:

   o  Address allocation and configuration mechanisms.

   o  Host mobility support: mobile nodes and correspondent nodes,
      either located within or outside the mobile network, are expected
      to continue operating protocols defined by the Mobile IP working
      group.  This include mechanisms for host mobility support (Mobile
      IPv6) and seamless mobility (FMIPv6).

   o  Multicast support intended for MNNs is expected to be maintained
      while the mobile router changes its point of attachment.

   o  Access control protocols and mechanisms used by visiting mobile
      hosts and routers to be authenticated and authorized, gaining
      access to the Internet via the mobile network infrastructure

   o  Security protocols and mechanisms.

   o  Mechanisms performed by routers deployed in both the visited
      networks and in mobile networks (routing protocols, Neighbor
      Discovery, ICMP, Router Renumbering).

3.9.  Secure Signaling

   NEMO support will have to comply with the usual IETF security
   policies and recommendations and is expected to have its specific
   security issues fully addressed.  In practice, all NEMO support
   control messages transmitted in the network will have to be protected
   with an acceptable level of security to prevent intruders to usurp
   identities and forge data.  Specifically, the following issues have
   to be considered:

   o  Authentication of the sender to prevent identity usurpation.

Ernst                     Expires May 12, 2007                  [Page 9]

Internet-Draft                 NEMO Goals                  November 2006

   o  Authorization, to make sure the sender is granted permission to
      perform the operation as indicated in the control message.

   o  Confidentiality of the data contained in the control message.

3.10.  Location Privacy

   Location privacy means to hide the actual location of MNNS to third
   parties other than the HA are desired.  It is not clear to which
   extend this has to be enforced, since it is always possible to
   determine the topological location by analysing IPv6 headers.  It
   would thus require some kind of encryption of the IPv6 header to
   prevent third parties from monitoring IPv6 addresses between the MR
   and the HA.  On the other hand, it is at the very least desirable to
   provide a means for MNNs to hide their real topological location to
   their CNs.

3.11.  IPv4 and NAT Traversal

   IPv4 clouds and NAT are likely to co-exist with IPv6 for a long time,
   so it is desirable to ensure mechanisms developed for NEMO will be
   able to traverse such clouds.

Ernst                     Expires May 12, 2007                 [Page 10]

Internet-Draft                 NEMO Goals                  November 2006

4.  NEMO Basic Support One-Liner Requirements

   For basic network mobility support, the NEMO WG is to specify a
   unified and unique "Network Mobility (NEMO) Basic Support" solution,
   hereafter referred to as "the solution".  This solution is to allow
   all nodes in the mobile network to be reachable via permanent IP
   addresses, as well as maintain ongoing sessions as the MR changes its
   point of attachment to the Internet topology.  This is to be done by
   maintaining a bi-directional tunnel between an MR and its Home Agent.

   The NEMO Working Group, after some investigation of alternatives, has
   decided to reuse and extend the existing Mobile IPv6 [5] mechanisms
   for tunnel management.

   The list of requirements below has been imposed on the NEMO Basic
   Support solution.  The requirements have mostly been met by the
   resulting specification which can now be found in [3].  Associated
   deployment issues are discussed in [9]

      R01: The solution MUST be implemented at the IP layer level.

      R02: The solution MUST set up a bi-directional tunnel between a
      Mobile Router and its Home Agent (MRHA tunnel)

      R03: All traffic exchanged between an MNN and a CN in the global
      Internet MUST transit through the bi-directional MRHA tunnel.

      R04: MNNs MUST be reachable at a permanent IP address and name.

      R05: The solution MUST maintain continuous sessions (both unicast
      and multicast) between MNNs and arbitrary CNs after IP handover of
      (one of) the MR.

      R06: The solution MUST not require modifications to any node other
      than MRs and HAs.

      R07: The solution MUST support fixed nodes, mobile hosts and
      mobile routers in the mobile network.

      R08: The solution MUST allow MIPv6-enabled MNNs to use a mobile
      network link as either a home link or a foreign link.

      R09: The solution MUST ensure backward compatibility with other
      standards defined by the IETF.  In particular, this includes:

         R09:1: The solution MUST not prevent the proper operation of
         Mobile IPv6 (i.e. the solution MUST allow MIPv6-enabled MNNs to
         operate either the CN, HA, or MN operations defined in [5])

Ernst                     Expires May 12, 2007                 [Page 11]

Internet-Draft                 NEMO Goals                  November 2006

      R10: The solution MUST treat all the potential configurations the
      same way (whatever the number of subnets, MNNs, nested levels of
      MRs, egress interfaces)

      R11: The solution MUST support at least 2 levels of nested mobile
      networks, while, in principle, arbitrary levels of recursive
      mobile networks SHOULD be supported.

      R12: The solution MUST function for multihomed MRs and multihomed
      mobile networks as defined in [1].

      R13: NEMO Support signaling over the bi-directional MUST be

      R14: Signaling messages between the HA and the MR MUST be secured:

         R14.1: The receiver MUST be able to authenticate the sender.

         R14.2: The function performed by the sender MUST be authorized
         for the content carried.

         R14.3: Anti-replay MUST be provided.

         R14.4: The signaling messages MAY be encrypted.

      R15: The solution MUST ensure transparent continuation of routing
      and management operations over the bi-directional tunnel (this
      includes e.g. unicast and multicast routing protocols, router
      renumbering, DHCPv6)

      R16: When one egress interface fails, the solution MAY preserve
      sessions established through another egress interface.

Ernst                     Expires May 12, 2007                 [Page 12]

Internet-Draft                 NEMO Goals                  November 2006

5.  Security Considerations

   As this document only provides a discussion about design goals and
   describes neither a protocol nor an implementation or a procedure,
   there are no security considerations associated with it.

Ernst                     Expires May 12, 2007                 [Page 13]

Internet-Draft                 NEMO Goals                  November 2006

6.  IANA Considerations

   This document requires no IANA actions.

Ernst                     Expires May 12, 2007                 [Page 14]

Internet-Draft                 NEMO Goals                  November 2006

7.  Acknowledgments

   The material presented in this document takes most of its text from
   discussions and previous documents submitted to the NEMO working
   group.  This includes initial contributions from Motorola, INRIA,
   Ericsson and Nokia.  We are particularly grateful to Hesham Soliman
   (Ericsson) and the IETF ADs at the time (Erik Nordmark and Thomas
   Narten) who greatly helped to set up the NEMO working group.  We are
   also grateful to all the following people whose comments highly
   contributed to the present document: T.J. Kniveton (Nokia), Alexandru
   Petrescu (Motorola), Christophe Janneteau (Motorola), Pascal Thubert
   (Cisco), Hong-Yon Lach (Motorola), Mattias Petterson (Ericsson) and
   all the others people who have expressed their opinions on the NEMO
   mailing lists (formely known as MONET).  Thierry Ernst wishes to
   personally acknowledge INRIA Rhone-Alpes and Motorola Labs Paris for
   their support and direction in bringing this topic up to the IETF
   back in year 2001 -- particularly Claude Castelluccia (INRIA) and
   Hong-Yon Lach (Motorola) -- and his past employer, Keio University,
   Japan which supported most of the costs associated with the IETF
   during the timelife of previous versions of this document.

Ernst                     Expires May 12, 2007                 [Page 15]

Internet-Draft                 NEMO Goals                  November 2006

8.  References

8.1.  Normative References

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

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

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

8.2.  Informative References

   [4]  "CALM - Medium and Long Range, High Speed, Air Interfaces
        parameters and protocols for broadcast, point to point, vehicle
        to vehicle, and vehicle to point communication in the ITS sector
        - Networking Protocol - Complementary Element", ISO Draft ISO/WD
        21210, February 2005.

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

   [6]  Ng, C., Pascal, P., Masafumi, M., and F. Fan, "Network Mobility
        Route Optimization Problem Statement",
        draft-ietf-nemo-ro-problem-statement-03 (work in progress),
        September 2006.

   [7]  Ng, C., Fan, F., Masafumi, M., and P. Pascal, "Network Mobility
        Route Optimization Solution Space Analysis",
        draft-ietf-nemo-ro-space-analysis-03 (work in progress),
        September 2006.

   [8]  Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of Multihoming in
        Network Mobility Support", draft-ietf-nemo-multihoming-issues-06
        (work in progress), June 2006.

   [9]  Thubert, P., Wakikawa, R., and V. Devarapalli, "NEMO Home
        Network Models", draft-ietf-nemo-home-network-models-06 (work in
        progress), February 2006.

Ernst                     Expires May 12, 2007                 [Page 16]

Internet-Draft                 NEMO Goals                  November 2006

Author's Address

   Thierry Ernst
   INRIA Rocquencourt
   Domaine de Voluceau B.P. 105
   Le Chesnay,   78153

   Phone: +33 1 39 63 59 30
   Fax:   +33 1 39 63 54 91
   Email: thierry.ernst@inria.fr
   URI:   http://www-rocq.inria.fr/imara

Ernst                     Expires May 12, 2007                 [Page 17]

Internet-Draft                 NEMO Goals                  November 2006

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

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

Ernst                     Expires May 12, 2007                 [Page 18]

Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/